On Mon, Feb 1, 2010 at 4:32 PM, Antoine Pitrou <solip...@pitrou.net> wrote: > Jesse Noller <jnoller <at> gmail.com> writes: >> >> I don't see the need for the change from fork as of yet (for >> multiprocessing) and I am leery to change the internal implementation >> and semantics right now, or anytime soon. I'd be interested in seeing >> the patch, but if the concern is that global threading objects could >> be left in the state that they're in at the time of the fork(), I >> think people know that or we can easily document this fact. > > If Pascal provides a patch I think it would really be good to consider it. > Not being able to mix threads and multiprocessing is a potentially annoying > wart. It means you must choose one or the other from the start, and once > you've > made this decision you are stuck with it. > (not to mention that libraries can use threads and locks behind your back) >
I don't see spawnl as a viable alternative to fork. I imagine that I, and others successfully mix threads and multiprocessing on non-win32 platforms just fine, knowing of course that fork() can cause heartburn if you have global locks code within the forked() processes might be dependent on. In fact multiprocessing uses threading internally. For the win32 implementation, given win32 doesn't implement fork(), see http://svn.python.org/view/python/trunk/Lib/multiprocessing/forking.py?view=markup, about halfway down. We already have an implementation that spawns a subprocess and then pushes the required state to the child. The fundamental need for things to be pickleable *all the time* kinda makes it annoying to work with. 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
