Re: wip-threads-and-fork

[Andy Wingo <wingo@pobox.com>]

Hi all,

An update on this issue.  For context:

On Wed 08 Feb 2012 23:10, Andy Wingo <wingo@pobox.com> writes:

> I was testing out the threaded web server and it was working well.  Then
> I tried it out with tekuti, a blog engine that uses git as the backend.
> It uses (ice-9 popen) to talk to the git binaries.  It was deadlocking
> and segfaulting and all kinds of things!
>
> The reason is that when you fork(), only the thread that calls fork()
> survives into the child.  If another thread was in a critical section --
> i.e., held a mutex -- it just stops.

One thing that I did not realize when I wrote this is that POSIX clearly
says that if a multithreaded program forks, the behavior of the child
after the fork is undefined if it calls any non-async-signal-safe
function before calling exec().

Go ahead and read that again, if you didn't catch it the first time.

Basically POSIX prohibits the generality of fork() if your program has
threads.  Guile has fork, and threads.  What to do?

Obviously we can treat the limited case of (ice-9 popen) in a more
portable fashion.

But then there is the question: why, in the name of all that is holy,
did POSIX specify pthread_atfork?  If its intention is to grab mutexes
around a fork, and mutex operations are not signal-safe, what are they
on about?

On Glibc, many things are likely to work.  Not all, of course -- witness
this bug:

> iconv_open() is threadsafe, but on glibc it loads gconv modules,
> within a lock.

Is the lack of a thread_atfork handler a glibc bug or not?  POSIX can
argue either way.

I filed http://sourceware.org/bugzilla/show_bug.cgi?id=13725 in any
case.  I'd rather not commit a workaround if it's a glibc bug, but what
about other platforms?  Do we in the Guile project have to choose
between threads and fork?

Andy
-- 
http://wingolog.org/