Re: dlopen() not locking shared object

[John Reiser <jreiser at teleport dot com>]

minyard@acm.org wrote:
> 
> Kaz Kylheku <kaz@ashi.footprints.net> writes:
> 
> > On 22 Oct 1999 minyard@acm.org wrote:
> >
> > > I'm looking for a way to load a shared object like dlopen() does, but
> > > without keeping the shared object file open.  I have an application
> > > where I need to mount an NFS volume, load a shared object completely,
> > > then unmount the NFS volume (I can't have NFS up all the time due
> > > to reliability concerns).
> >
> > Copy the object to a local filesytem, then dlopen the copy.
> 
> I have no local filesystem but a ramdisk and all the files would
> quickly fill up the ramdisk unless I made it quite large (larger than
> I can afford).  And if I did that, I would basically have two copies
> of the data in memory, one as the load an one in the ramdisk (I don't
> think mmap will "know" it is really in memory and not copy it).
> Unfortunately, I don't think that solution will work.
> 
> So, I ask my question again.
> 
> Corey

One of the failings of dlopen is that it discriminates against
immediate constants (such as an array which happens to have the
file already read into it), and instead requires the bits to
have indirection and a pedigree (by living in a filesystem).

It seems to me that what you want will require some programming,
either to make dlopen honor the array, or to make a loopback device
connected to the array or to a piece of /dev/mem or /dev/swap.

-- 
John Reiser,jreiser@teleport.com