Date: Tue, 29 Apr 2003 15:14:27 -0400 (EDT) From: Daniel Eischen <eischen@pcnet1.pcnet.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: threads@freebsd.org Subject: Re: Question about rtld-elf. Anyone?.. Anyone? Message-ID: <Pine.GSO.4.10.10304291512190.2144-100000@pcnet1.pcnet.com> In-Reply-To: <3EAEC9D2.AE47CC0A@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10304291512190.2144-100000>