Re: Patch for install: allow to change prototype

[Ilya Zakharevich <ilya@Math.Berkeley.EDU>]

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.