threaded, forked, rethreaded processes will deadlock

[Brian Fundakowski Feldman]

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.

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\