[issue6721] Locks in python standard library should be sanitized on fork
Steffen Daode Nurpmeso
report at bugs.python.org
Tue May 17 12:35:25 CEST 2011
Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:
@ 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.)
----------
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________
More information about the Python-bugs-list
mailing list