Jesse Noller <jnoller <at> gmail.com> writes: > > 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). It's certainly much more practical to give a choice in multithreading than ask all libraries writers to eliminate global locks. > We already have an implementation that spawns a > subprocess and then pushes the required state to the child. 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? > The > fundamental need for things to be pickleable *all the time* kinda > makes it annoying to work with. Oh, sure. But if you want to be Windows-compatible you'd better comply with this requirement anyway. Regards Antoine. _______________________________________________ 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
