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 _______________________________________________ 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
