This is the mail archive of the glibc-linux@ricardo.ecn.wfu.edu mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: dlopen() not locking shared object


John Reiser <jreiser@teleport.com> writes:
> 
> 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.
> 

I don't exactly follow what you are saying, but I think that is
correct.  It seems to me the easiest and most flexible and useful (to
others) way to do this would be to provide a new flag to dlopen() that
causes it to allocate the memory and copy the file data into it
instead of mmap()-ing the file parts in.  The normal operation would
still be to mmap the file, but if the flag was provided it would
allocate and copy the data in.  I would be willing to do the work and
provide a patch, but if someone has a better way I'd rather use that.
I haven't thought of one and I was asking to be sure and asking if the
patch would be accepted or if there was some fundamental problem with
it.

Corey

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]