On Mon, Feb 1, 2010 at 5:08 PM, Antoine Pitrou <solip...@pitrou.net> wrote:
>> 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. > > Sure. But sometimes global locks are out of your control. They can be e.g. in > a > library (Pascal gave the example of the logging module; we may have more of > them > in the stdlib). 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". > It's certainly much more practical to give a choice in multithreading than ask > all libraries writers to eliminate global locks. Trust me, I'm all for giving users choice, and I'd never turn down help - I'm just doubtful/wary on this count. If we wanted a fork-free non-windows implementation, ala the current win32 implementation, then we should just clone the windows implementation and work forward from there. > I know, and that's why it wouldn't be a very controversial change to add an > option to enable this path under Linux, would it? Fair enough; but then you have the additional problem of trying to explain to users the difference between multiprocessing.Process(nofork=True) or .Process(fork=False) or whatever argument we'd decide to use "use this if you have no threads, global locks, etc, etc". > Oh, sure. But if you want to be Windows-compatible you'd better comply with > this > requirement anyway. > Kinda, sorta. So far, 99% of the multiprocessing code I've seen doesn't attempt to be compatible with both unixes, and win32 - commonly, it's either win32 *or* linux. Obviously, being compatible with both means picking the lowest common denominator. 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
