threaded, forked, rethreaded processes will deadlock

[Daniel Eischen]

On Fri, 9 Jan 2009, Brian Fundakowski Feldman wrote:

> On Thu, Jan 08, 2009 at 10:44:20PM -0500, Daniel Eischen wrote:
>> On Thu, 8 Jan 2009, Brian Fundakowski Feldman wrote:
>>
>>> It appears that the post-fork hooks for malloc(3) are somewhat broken such that
>>> when a threaded program forks, and then its child attempts to go threaded, it
>>> deadlocks because it already appears to have locks held.  I am not familiar
>>> enough with the current libthr/libc/rtld-elf interaction that I've been able
>>> to fix it myself, unfortunately.
>>
>> There's really nothing to fix - according to POSIX you are only
>> allowed to call async-signal-safe functions in the child forked
>> from a threaded process.  If you are trying to do anything other
>> than that, it may or may not work on FreeBSD, but it is not
>> guaranteed and is not portable.
>>
>> The rationale is that what is the point of forking and creating
>> more threads, when you can just as easily create more threads in
>> the parent without forking?  The only reason to fork from a threaded
>> process is to call one of the exec() functions.
>
> Well, it worked until the last major set of changes to malloc.  For me, the point
> was that I was able to have transparent background worker threads in any program
> regardless of its architecture, using the standard pthread fork hooks.  Could you
> point me to the POSIX section covering fork and threads?  If it's really not
> supposed to work then that's fine, but there's an awful lot of code there dedicated
> to support going threaded again after a fork.

I don't know if this link will work for you, but you can
start here:

   http://www.opengroup.org/onlinepubs/009695399/nframe.html

   "It is suggested that programs that use fork() call an exec
    function very soon afterwards in the child process, thus
    resetting all states. In the meantime, only a short list of
    async-signal-safe library routines are promised to be available."


-- DE
--