Hi all, An update on this issue. For context:
On Wed 08 Feb 2012 23:10, Andy Wingo <wi...@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/
