Don G <dongryphon <at> yahoo.com> writes:
Of the mechanisms discussed, I am not sure I understand what you mean by async I/O with only one thread. I can imagine a nonblocking/select style approach that has no extra threads, but as soon as the main thread is not waiting on I/O itself (my interpretation of "async"), there needs to be threads to do the waiting. Unless I am missing something (which happens often<g>) or we are having terminology problems (also a frustratingly frequent occurrence).
You should take a look at the python Twisted framework <http://twistedmatrix.com/>. There are performance issues in python with threads because of the Global Interpreter Lock (GIL). The framework is a workaround, performing every task in an asynchronous way from a single thread. The design of the Defer class is interesting and is the key of asychronous tasks control flows (<http://twistedmatrix.com/projects/core/documentation/howto/defer.html>). By the way, there were and will be lengthy discussions about which approach is the "best" to build scalable concurrent programs. I think that multithreading and event-driven programming were proven to be equivalent from a theorical point of view, but there real differences in implementation. You could read this one and many items from its bibliography too: <http://capriccio.cs.berkeley.edu/pubs/threads-hotos-2003.pdf> (The Capriccio project was really interesting too, on the paper. I do not know where they are now). Patrick Mézard