On Feb 1, 2010, at 6:25 PM, Michael Foord <fuzzy...@voidspace.org.uk>
wrote:
On 01/02/2010 23:03, Reid Kleckner wrote:
On Mon, Feb 1, 2010 at 5:48 PM, Jesse Noller<jnol...@gmail.com>
wrote:
Your reasonable argument is making it difficult for me to be
irrational
about this.
No problem. :)
This begs the question - assuming a patch that clones the behavior
of win32
for multiprocessing, would the default continue to be forking
behavior, or
the new?
Pros of forking:
- probably faster (control doesn't start back at Py_Main)
- more shared memory (but not that much because of refcounts)
- objects sent to child processes don't have to be pickleable
Cons:
- leaks memory with threads
- can lead to deadlocks or races with threads
I think the fork+exec or spawnl version is probably the better
default
because it's safer. If people can't be bothered to make their
objects
pickleable or really want the old behavior, it can be left as an
option.
Wouldn't changing the default be backwards incompatible?
Michael
Yes, it would, which is why it would have to be a switch for 2.x, and
could only possibly be changed/broken for 3.x.
Note, this is only off the top of my head, if Pascal is still game to
do a patch (skipping spawnl, and going with something more akin to the
current windows implementation) and it comes out as agreeable to all
parties the exact integration details can be worked out then.
Part of me wonders though - this is a problem with python, fork and
threads in general. Things in the community such as gunicorn which are
"bringing forking back" are going to slam into this to.
Jesse
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
