[Python-3000] the future of the GIL
rasky at develer.com
Wed May 9 11:07:45 CEST 2007
On 07/05/2007 7.36, Josiah Carlson wrote:
> By going multi-process rather than multi-threaded, one generally removes
> shared memory from the equasion. Note that this has the same effect as
> using queues with threads, which is generally seen as the only way of
> making threads "easy". If one *needs* shared memory, we can certainly
> create an mmap-based shared memory subsystem with fine-grained object
> locking, or emulate it via a server process as the processing package
> has done.
> Seriously, give the processing package a try. It's much faster than one
> would expect.
I'm fully +1 with you on everything.
And part of the fact that we have to advocate this is because Python has
always had pretty good threading libraries, but not processing libraries;
actually, Python does have problems at spawning processes: the whole
popen/popen2/subprocess mess isn't even fully solved yet.
One thing to be said, though, is that using multiple processes cause some
headaches with frozen distributions (PyInstaller, py2exe, etc.), like those
usually found on Windows, specifically because Windows does not have fork().
The processing module, for instance, doesn't take this problem into account at
all, making it worthless for many of my real-world use cases.
More information about the Python-3000