Message136147
| Author |
sdaoden |
| Recipients |
bobbyi, gregory.p.smith, neologix, nirai, pitrou, sdaoden, vstinner |
| Date |
2011年05月17日.10:35:24 |
| SpamBayes Score |
6.093015e-12 |
| Marked as misclassified |
No |
| Message-id |
<20110517103517.GA82726@sherwood.local> |
| In-reply-to |
<1305572250.09.0.136537638335.issue6721@psf.upfronthosting.co.za> |
| Content |
@ 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.) |
|