[Python-ideas] [Python-3000] the future of the GIL

Leonardo Santagada santagada at gmail.com
Wed May 9 15:20:15 CEST 2007


Em 09/05/2007, às 06:07, Giovanni Bajo escreveu:

> 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.
> -- 
> Giovanni Bajo

Another problem is that althought people like the idea of processing  
more, the only module on python stdlib is thread and Threading... So  
why not include processing in stdlib and in both thread and Threading  
give pointers to its use? This would probably diminish the problem  
with newcomers on the language that hate the GIL because they don't  
know better (and also because threading is supported out of the box  
on python). Yes I know there is fork, but still it is not as useable  
and pythonic as processing.


--
Leonardo Santagada
santagada at gmail.com






More information about the Python-ideas mailing list