Hello! (With delay...)
Andy Wingo <wi...@pobox.com> skribis: > I would have preferred this, but I came to the conclusion that this > approach is not sound. Without exposing ‘pthread_atfork’, how would you suggest making user code “fork-safe”? A use case would be reviving the futures thread pool after ‘fork’. > Did you see that I merged the atfork bits into master? > (wip-threads-and-fork also had some CLOEXEC bits that needed more > baking). They worked... sorta. They had a few problems: > > 1) It's impossible to work around the lack of atfork() in libraries > that you depend on. > > For example, wip-threads-and-fork called fork() within the GC alloc > lock, to get around the lack of a pthread_atfork() in libgc. But > then I submitted a patch to make libgc do this itself: > > > http://thread.gmane.org/gmane.comp.programming.garbage-collection.boehmgc/4940 > > It's pretty difficult to tell which version of libgc you would > have. There is no workaround that is sufficient. Indeed, good point. > 2) POSIX explicitly disclaims the result of calling non-signal-safe > primitives after a fork() of a multithreaded program. Right, though reality seems to be more pleasant than POSIX. ;-) > 3) Nobody cares about these bugs. See e.g. the lack of response at > http://sourceware.org/bugzilla/show_bug.cgi?id=13725. Even Bruno > didn't reply to the Cc. See point (2). > > 4) The atfork mechanism imposes a total ordering on locks. This is > possible for static locks, but difficult for locks on collectable > Scheme objects. > > 5) Relatedly, just to be able to lock all weak tables at a fork, we > had to create a new weak table-of-tables and add the tables to it. > This is needless complication and overhead. > > 6) scm_c_atfork() is a broken interface. Because it hangs its hooks > off of one pthread_atfork() invocation, it can cause newer locks to > insert themselves in the wrong position relative to > pthread_atfork() calls made between when Guile installed the > scm_c_atfork handler, and the call to scm_c_atfork. > > There can be only one pthread_atfork() list, in a correct program. OK, thanks for the nice summary. Indeed, this is a complex story. > In the end I reverted those patches because they were just complication > that didn't solve any fundamental problems. OK. > I came to the opinion, having run a threaded, forking program, that we > would be much better off if we provided good abstractions to spawn > processes, but that expecting fork() to work in a multithreaded program > is not realistic. Yes, things like ‘open-process’ make sense. What about adding a big fat warning in the doc about use of ‘primitive-fork’ in a multi-threaded program? > Still, there is one other thing that perhaps we could do to shut down > the signal handling thread around a fork(). Dunno, perhaps it is worth > looking into. What would be the expected benefit? Thanks, Ludo’.
