[issue6721] Locks in python standard library should be sanitized on fork

[Steffen Daode Nurpmeso]

Steffen Daode Nurpmeso <sdaoden at googlemail.com> added the comment:

> How do you think multiprocessing.Process launches a new process?

But it's a single piece of code under control and even
multi-OS/multi-architecture test-coverage, not a general purpose
"Joe, you may just go that way and Python will handle it
correctly"?

What i mean is: ten years ago (or so), Java did not offer true
selection on sockets (unless i'm mistaken) - servers needed a 1:1
mapping of threads:sockets to handle connections?!
But then, a "this thread has finished the I/O, let's use it for
something different" seems to be pretty obvious.
This is ok if it's your professor who is forcefully misleading
you into the wrong direction, but otherwise you will have
problems, maybe sooner, maybe later (, maybe never).  And
currently there is not a single piece of documentation which
points you onto the problems.  (And there *are* really people
without Google.)

The problem is that it looks so simple and easy - but it's not.
In my eyes it's an unsolvable problem.  And for the sake of
resource usage, simplicity and execution speed i appreciate all
solutions which don't try to do the impossible.

I want to add that all this does not really help just as long just
*any* facility which is used by Python *itself* is not under control
of atfork.  Solaris e.g. uses atfork for it's memory allocator,
because that is surely needed if anything else but async-safe
facilities are used in the newly forked process.  Can Python give
that guarantee for all POSIX systems it supports?

Good night.
--
Ciao, Steffen
sdaoden(*)(gmail.com)
() ascii ribbon campaign - against html e-mail
/\ www.asciiribbon.org - against proprietary attachments

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue6721>
_______________________________________