On Feb 1, 2010, at 5:35 PM, Reid Kleckner <r...@mit.edu> wrote:
On Mon, Feb 1, 2010 at 5:18 PM, Jesse Noller <jnol...@gmail.com>
wrote:
I don't disagree there; but then again, I haven't seen this issue
arise (in my own code)/no bug reports/no test cases that show this to
be a consistent issue. I'm perfectly OK with being wrong, I'm just
leery to tearing out the internals for something else "not forking".
I'd appreciate it. It made my life a lot harder when trying to move
JIT compilation to a background thread, for exactly the reasons we've
been talking about. All the locks in the queue can be left in an
undefined state. I solved my problem by digging into the posix
module and inserting the code I needed to stop the background thread.
Another problem with forking from a threaded Python application is
that you leak all the references held by the other thread's stack.
This isn't a problem if you're planning on exec'ing soon, but it's
something we don't usually think about.
It would be nice if threads + multiprocessing worked out of the box
without people having to think about it. Using threads and fork
without exec is evil.
Reid
Your reasonable argument is making it difficult for me to be
irrational about this.
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?
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
