Kill GIL

[Nick Coghlan]

Mike Meyer wrote:
> aahz at pythoncraft.com (Aahz) writes:
>>Threads are also good for handling blocking I/O.
> 
> Actually, this is one of the cases I was talking about. I find it
> saner to convert to non-blocking I/O and use select() for
> synchronization. That solves the problem, without introducing any of
> the headaches related to shared access and locking that come with
> threads.

Use a communicating sequential processes model for the threading and you don't 
have many data synchronisation problems because you have barely any shared 
access - no application data is ever shared between threads, they only send 
messages to each other via message queues. Most threads simply block on their 
incoming message queue permanently. Those doing blocking I/O set an appropriate 
timeout on the I/O call so they can check for messages occasionally.

Conveniently, you end up with an architecture that supports switching to 
multiple processes, or even multiple machines just by changing the transport 
mechanism used by the message system.

(We did exactly this for a GUI application - detached the GUI so it talked to a 
server via CORBA instead of via direct DLL calls. This meant the server could be 
ported to a different platform without having to port the far more platform 
specific GUI. This would have been much harder if we weren't already using a CSP 
model for communication between different parts of the system)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at email.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.skystorm.net