|Ilya Zakharevich on Tue, 26 Nov 2002 16:56:34 -0800|
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
|Re: Patch for install: allow to change prototype|
On Tue, Nov 26, 2002 at 10:17:07PM +0100, Bill Allombert wrote: > > If I understand it correct, the *only* information we keep about the > > address space of the external library is an entry in entree. Thus it > > should be safe to do dlclose() at the appropriate time. (Note that > > Perl has no notion of unloading a module due to much more flexible > > interface, thus uncontrollable "pollution" of data with addresses from > > the library.) > > As I understand, the problem is not so much if doing dlclose() is safe, it is > wether dlclose() will really unload the module so that a subsequent dlopen() > load the new module, especially if it has the same filename that the previous > one. I have a problem visualizing which particular botched implementation of dynaloading you have in mind. The problem *I* have in mind is that doing dlclose()/dlopen() pair would load the segments of the DLL into different address ranges. Thus if you keep a pointer to a data in the old address range, going through this pointer would lead to problems. Given that typically PARI keeps such pointers in a very controllable manner, we can do quite well in this respect. Ilya P.S. src/systems/os2.c does not implement dlclose(), but it would, the semantic would be the following: on the nth call to dlclose() (here n is the number of times dlopen() was called) the module will go out of memory (unless it was required by the executable). I expect that many systems have a similar semantic.