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

[Daniel Eischen]

On Tue, 29 Apr 2003, Narvi wrote:
> 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.

Locks are not used unless __isthreaded is true.  After a fork(),
__isthreaded gets set back to 0 so locks are not used.  Assuming
rtld were changed to use the same types of locks that libc uses
(which jdp suggests isn't the best way), you would take the
same approach.  So no matter what state the locks were in,
as long as you didn't become threaded again, you wouldn't
attempt to use the lock.

Usually fork()s from threaded applications are not to launch
another threaded instance of the application.  Even so, we
still would like this to work.

-- 
Dan Eischen