[EMAIL PROTECTED] (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 | [EMAIL PROTECTED] | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.skystorm.net
--
http://mail.python.org/mailman/listinfo/python-list
