On Tue, Feb 2, 2010 at 10:34 AM, Pascal Chambon <chambon.pas...@gmail.com> wrote: > > > > The word "dogma" is a good one in this context however. "We" ( ;-)) have > accepted and promoted the dogma that multiprocessing is the solution to > parallelism in the face of the GIL. While it needn't be applicable in any > and > every situation, we should make it so that it is applicable often enough. > > > Again, wishing won't make it so: there is no sane way to mix threading > and fork-without-exec except by keeping the parent process single > threaded until after any fork() calls. Some applications may seem to > work when violating this rule, but their developers are doomed to hair > loss over time. > > > > You pointed it out : fork() was not designed to work together with > multithreading ; furthermore in many cases its data-duplication semantic is > absolutely unneeded to solve the real problem. > > So we can let fork-without-exec multiprocessing (with or without threads) > for those who need it, and offer safer multiprocessing for those who just > seek use of ease and portability - via spawn() semantic. > > Regards, Pascal
And I've migrated to the camp wherein the safer semantics should be the default semantics. However, once we have a patch, I'm going to socialize it with some of the heavier multiprocessing users *I* know of to get feedback. 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
