Question about rtld-elf. Anyone?.. Anyone?

[Narvi]

On Tue, 29 Apr 2003, Daniel Eischen wrote:

> On Tue, 29 Apr 2003, Narvi wrote:
> > [snip]
> >
> > > ...
> > > This is a short-term fix for a larger problem.  The use of spinlocking
> > > isn't guaranteed to work in all cases.  For example, if the spinning
> > > thread has higher priority than all other threads, it may never be
> > > pre-empted, and the thread holding the lock may never progress far
> > > enough to release the lock.  On the other hand, spinlocking is the
> > > only locking that can work with an arbitrary unknown threads package.
> > >
> > > I have some ideas for a much better fix in the longer term.  It
> > > would eliminate all locking inside the dynamic linker by making it
> > > safe for symbol lookups and lazy binding to proceed in parallel
> > > with a call to dlopen or dlclose.  This means that the only mutual
> > > exclusion needed would be to prevent multiple simultaneous calls
> > > to dlopen and/or dlclose.  That mutual exclusion could be put into
> > > the native pthreads library.  Applications using foreign threads
> > > packages would have to make their own arrangements to ensure that
> > > they did not have multiple threads in dlopen and/or dlclose -- a
> > > reasonable requirement in my opinion.
> > > ====
> > >
> > > Basically he's describing the exact scenario you're concerned about.  The
> > > last paragraph suggests a better way.
> > >
> >
> > You will then need to make sure something sensible (and not a deadlock)
> > happens if fork() gets called at a time when dlopen() / dlclose() is
> > running in another thread.
>
> How is this any different than spinlocks or mutexes used
> in libc (malloc, free, etc)?
>

its not, really. locks in the dynamic linker usualy just make things a bit
more interesting than locks elsewhere.

> Yes, this is true, but no threads library that we have currently
> tracks internal locks so they can be reinitialized after a fork.
> It is possible that a fork() will leave things in the locked
> state.  But even if they were locked, you'd only see a problem
> if the forked program again became threaded.
>

No, you would see the problem as soon as you tried to use a function that
used a locked structure, depending on how the dynamic linker did thinks
this might include any fiunction, including exec* - threads + forking
gives you really fascinating problems. How do you know that say malloc
state was consistent at the moment you forked? You really need
per-subsystem cleanups so that you won't occasionaly fail miserably. Its
not really the threads lib that can / should track locks, unless it comes
with its own copy of the subsystems.

> We do need to fix this, and it is one of the things on my
> TODO list.
>
> --
> Dan Eischen
>