[Python-Dev] Improved thread switching

[Nick Coghlan]

Facundo Batista wrote:
> 2008/3/20, Andrew McNabb <amcnabb at mcnabbs.org>:
> 
>> Since we officially encourage people to spawn processes instead of
>>  threads, I think that this would be a great idea.  The processing module
>>  has a similar API to threading.  It's easy to use, works well, and most
>>  importantly, gives us some place to point people to when they complain
>>  about the GIL.
> 
> I'm +1 to include the processing module in the stdlib.
> 
> just avoid confussions, with these libraries with alike names, I'm
> meaning this [1] module, the one that emulates the semantics of
> threading module.
> 
> Does anybody has strong reasons for this module to not get included?

Other than the pre-release version number and the fact that doing such a 
thing would require R. Oudkerk to actually make the offer rather than 
anyone else? There would also need to be the usual thing of at least a 
couple of people stepping up and being willing to maintain it.

I also wouldn't mind seeing some performance figures for an application 
that was limited to making good use of only one CPU when run with the 
threading module, but was able to exploit multiple processors to obtain 
a speed improvements when run with the processing module.

That said, I'm actually +1 on the general idea, since I always write my 
threaded Python code using worker threads that I communicate with via 
Queue objects. Pyprocessing would be a great way for me to scale to 
multiple processors if I was running CPU intensive tasks rather than 
potentially long-running hardware IO operations (I've been meaning to 
check it out for a long time, but have never actually needed to for 
either work or any home projects).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org