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