@ 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.)