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

[Daniel Eischen]

On Tue, 29 Apr 2003, Terry Lambert wrote:

> Narvi wrote:
> > Peter Wemm wrote:
> > > 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.
> 
> I think this is a non-sequitur; what's "sensible" in that case?
> Should the address space of the fork()'ed process contain the
> dlopen()'ed object, or not?
> 
> It seems to me that this situation is a coding error on the part
> of the person who did not manually serialize access through a
> pthread mutex, so that the address space was controlled over the
> fork(), and the resulting process ended up with the state of its
> address space known to the programmer.

Indeed.  POSIX also has this to say about fork():

    A process shall be created with a single thread.  If a multi-threaded
    process calls fork(), the new process shall contain a replica of the
    calling thread and its entire address space, possibly including the
    states of mutexes and other resources.  Consequently, to avoid errors,
    the child process may only execute async-signal-safe operations until
    such time as one of the exec functions is called.  Fork handlers may
    be established by means of the pthread_atfork() function in order to
    maintain application invariants across fork() calls. 

    When the application calls fork() from a signal handler and any of the
    fork handlers registered by pthread_atfork() calls a function that is
    not asynch-signal-safe, the behavior is undefined.

-- 
Dan Eischen