@ Nir Aides wrote (2011-05-16 20:57+0200): > Steffen, can you explain in layman's terms? I am the layman here. Charles-François has written a patch for Python which contradicted his own proposal from msg135079, but he seems to have tested a lot so that he then was even able to prove that his own proposal was correct. His new patch does implement that with a nice introductional note. He has also noticed that the only really safe solution is to simply disallow multi-threading in programs which fork(). And this either-or is exactly the conclusion we have taken and implemented in our C++ library - which is not an embeddable programming language that needs to integrate nicely in whatever environment it is thrown into, but "even replaces main()". And i don't know any application which cannot be implemented regardless of fork()-or-threads instead of fork()-and-threads. (You *can* have fork()+exec()-and-threads at any time!) So what i tried to say is that it is extremely error-prone and resource intensive to try to implement anything that tries to achieve both. I.e. on Solaris they do have a forkall() and it seems they have atfork handlers for everything (and even document that in the system manual). atfork handlers for everything!! And for what? To implement a standart which is obviously brain-dead because it is *impossible* to handle it - as your link has shown this is even confessed by members of the committee. And writing memory in the child causes page-faults. That's all i wanted to say. (Writing this mail required more than 20 minutes, the mentioned one was out in less than one. And it is much more meaningful AFAIK.)