Mailing List Archive

embedding perl && dl_next.xs
I have received a request to modify the dl_next.xs code for the
specific needs that arise from embedding perl and running multiple
interpreters at a time.

While the patch by Gerd Knops (forwarded to me by Anno Siegel) would
be a handy short-term solution, I want to ask you, what would be the
appropriate *portable* one.

The problem is, according to Gerd, that with multiple interpreters
libraries are loaded more than once resulting in rld errors.

How is that addressed in the other dl_*.xs implementations? Is that
something we should let the Dynaloader take care of? Is that already
solved on other architectures?

I append the patch suggested by Gerd below. I ran the standard tests
on it and Tk/widget and have (as expected) no problem so far.

I realize the potential problem of using the absolute pathname to
identify an already loaded object. This must be addressed (if the
interpreters have different @INC paths, they could find the same
labrary in different places). But I'm not deep enough in the problem
to suggest a better way.


Please CC your answers to Gert and Anno, both included in the header.

Thanks,
andreas

--- ../../../perl5.001m.1-orig/ext/DynaLoader/dl_next.xs Tue Oct 18 17:28:25 1994
+++ dl_next.xs Sat Sep 2 15:13:46 1995
@@ -83,13 +83,34 @@
char * path;
int mode; /* mode is ignored */
{
+/*****new*******/
+ static char **dl_next_loaded=NULL;
+/***************/
int rld_success;
NXStream *nxerr = OpenError();
AV * av_resolve;
I32 i, psize;
char *result;
char **p;
-
+
+/*****new*******/
+ /*
+ Do not load what is already loaded!
+ */
+ if(dl_next_loaded)
+ {
+ p=dl_next_loaded;
+ while(*p)
+ {
+ if(!strcmp(*p,path))
+ {
+ return path;
+ }
+ p++;
+ }
+ }
+/***************/
+
av_resolve = GvAVn(gv_fetchpv(
"DynaLoader::dl_resolve_using", FALSE, SVt_PVAV));
psize = AvFILL(av_resolve) + 3;
@@ -104,6 +125,28 @@
safefree((char*) p);
if (rld_success) {
result = path;
+/*****new*******/
+ {
+ /* Memorize what is already loaded */
+ if(!dl_next_loaded)
+ {
+ dl_next_loaded=malloc(sizeof(char *));
+ dl_next_loaded[0]=NULL;
+ }
+ p=dl_next_loaded;
+ i=0;
+ while(*p)
+ {
+ p++;
+ i++;
+ }
+ dl_next_loaded=realloc(dl_next_loaded,(i+1)*sizeof(char
+*));
+ dl_next_loaded[i]=malloc(strlen(path)+1);
+ strcpy(dl_next_loaded[i],path);
+ dl_next_loaded[i+1]=NULL;
+ }
+/***************/
} else {
TransferError(nxerr);
result = (char*) 0;
Re: embedding perl && dl_next.xs [ In reply to ]
> From: Andreas Koenig <k@anna.mind.de>
>
> I have received a request to modify the dl_next.xs code for the
> specific needs that arise from embedding perl and running multiple
> interpreters at a time.
>
> While the patch by Gerd Knops (forwarded to me by Anno Siegel) would
> be a handy short-term solution, I want to ask you, what would be the
> appropriate *portable* one.
>
> The problem is, according to Gerd, that with multiple interpreters
> libraries are loaded more than once resulting in rld errors.
>
> How is that addressed in the other dl_*.xs implementations?

It's not.

> Is that something we should let the Dynaloader take care of?

probably.

> Is that already solved on other architectures?
>
I don't think so.

> I append the patch suggested by Gerd below. I ran the standard tests
> on it and Tk/widget and have (as expected) no problem so far.
>
> I realize the potential problem of using the absolute pathname to
> identify an already loaded object. This must be addressed (if the
> interpreters have different @INC paths, they could find the same
> labrary in different places). But I'm not deep enough in the problem
> to suggest a better way.
>
The DynaLoader goes to some lengths to only use absolute paths.
The only problem I can see is people having the same dir on the
path more than once using different names (via symlinks) _and_
changing the search order between loads. Seems unlikely!

> Please CC your answers to Gert and Anno, both included in the header.
>
Since I have an outstanding task to consolidate/check the DynaLoader
'non-lazy' patch I'll look into doing something like this as a
utility that the dl_*.c code can use if needed on that platform.

I envisage dl_load_file() checking an HV* for the file path. If found
it would return the cached 'handle'. If not it would load the file and
add the new handle to the cache before returning it.

That would make the process-wide 'load only once' issue transparent to
the interpreter which still needs to be able to install extensions in
each interpreter.

Does that seem okay?

Tim.
Re: embedding perl && dl_next.xs [ In reply to ]
>The DynaLoader goes to some lengths to only use absolute paths.
>The only problem I can see is people having the same dir on the
>path more than once using different names (via symlinks) _and_
>changing the search order between loads. Seems unlikely!

I was thinking of a machine with more than one perl version installed
and more than one library trees. The probability to have a library
loaded twice because of such a situation is certainly low, and can be
neglected.

>
>> Please CC your answers to Gert and Anno, both included in the header.
>>
>Since I have an outstanding task to consolidate/check the DynaLoader
>'non-lazy' patch I'll look into doing something like this as a
>utility that the dl_*.c code can use if needed on that platform.

Great!

>
>I envisage dl_load_file() checking an HV* for the file path. If found
>it would return the cached 'handle'. If not it would load the file and
>add the new handle to the cache before returning it.
>
>That would make the process-wide 'load only once' issue transparent to
>the interpreter which still needs to be able to install extensions in
>each interpreter.
>
>Does that seem okay?

I think so.

>
>Tim.
>

Thanks!
andreas
Re: embedding perl && dl_next.xs [ In reply to ]
The DynaLoader goes to some lengths to only use absolute paths.
The only problem I can see is people having the same dir on the
path more than once using different names (via symlinks) _and_
changing the search order between loads. Seems unlikely!

how about doing an lstat on it and saving that data as well,
instead of just the path name ?

.mrg.
Re: embedding perl && dl_next.xs [ In reply to ]
In <9509041718.ab11340@post.demon.co.uk>
On Mon, 4 Sep 1995 15:19:45 +0100
Tim Bunce <Tim.Bunce@ig.co.uk> writes:
>> The problem is, according to Gerd, that with multiple interpreters
>> libraries are loaded more than once resulting in rld errors.
>>
>> How is that addressed in the other dl_*.xs implementations?
>
>It's not.
And SunOS won't like it either.

>
>> Is that already solved on other architectures?
>>
>I don't think so.
Solaris is probably immune - I think it does the cache, and return pointer
to previous in the dlopen() code.

>>
>The DynaLoader goes to some lengths to only use absolute paths.
>The only problem I can see is people having the same dir on the
>path more than once using different names (via symlinks) _and_
>changing the search order between loads. Seems unlikely!
>
>> Please CC your answers to Gert and Anno, both included in the header.
>>
>Since I have an outstanding task to consolidate/check the DynaLoader
>'non-lazy' patch I'll look into doing something like this as a
>utility that the dl_*.c code can use if needed on that platform.
>
>I envisage dl_load_file() checking an HV* for the file path. If found
>it would return the cached 'handle'. If not it would load the file and
>add the new handle to the cache before returning it.

On Unix-ish machines if you made key to hash dev/inode pair from stat()
you would avoid link issues - but probably not worth it.

>
>That would make the process-wide 'load only once' issue transparent to
>the interpreter which still needs to be able to install extensions in
>each interpreter.

That sounds okay.
Re: embedding perl && dl_next.xs [ In reply to ]
> > Is that already solved on other architectures?
> >
> I don't think so.

I'm pretty sure this won't be a problem for HP-UX. Either it doesn't care,
or the kernel keeps track of which libraries have already been loaded.

Jeff