[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: obsoleting shlibs - what's the plan
On Mon, Apr 14, 2008 at 03:52:02AM +0000, David Holland wrote:
> On Sat, Mar 29, 2008 at 12:36:14PM +0900, Joerg Sonnenberger wrote:
> > > It's also not clear that loading two instances of the "same" library
> > > is necessary wrong in all cases. For example, a library that provided
> > > the functions in <string.h> could be cloned fairly safely, whereas two
> > > different mallocs is clearly a losing proposition no matter what you
> > > do.
> > A different malloc is actually safe as well as long as you implement the
> > whole family.
> Not really. If a pointer returned by one malloc's malloc makes its way
> to the other malloc's free, nothing good can possibly happen.
I am not talking about mixing mallocs. I am talking about *replacing*
one completely. Given that it is not supposed to have a hidden
interface, it has to work. The list of symbols to override has recently
changed though as some people assumed posix_memalign is a bright idea.
> Also, with many malloc implementations they'll fight over the process
> break and get seriously confused.
I would expect a modern malloc implement to not use anachronistic
interfaces. mmap is almost always superior to break.
> > At least libpthread and libc should check explicitly that
> > they are loaded only once. In the caes of libpthread, it should also
> > check and fail miserable when it is loaded via dlopen.
> It's not clear that this can be done without help from the dynamic
Constructor is enough for libc and libpthread has an explicit init call
already. It just has to also implement a counter shared by the
Main Index |
Thread Index |