[Responding to a different message that also pertains to the reactors thread]
On Thu, Oct 11, 2012 at 6:38 PM, Mark Adam
Here's the thing: the underlying O.S is always handling two major I/O channels at any given time and it needs all it's attention to do this: the GUI and one of the following (network, file) I/O. You can shuffle these around all you want, but somewhere the O.S. kernel is going to have to be involved, which means either portability is sacrificed or speed if one is going to pursue and abstract, unified async API.
I'm convinced that the OS has to get involved. I'm not convinced that it will get in the way of designing an abstract unified API -- however that API will have to be more complicated than the kind of event loop that *only* handles network I/O or the kind that *only* handles GUI events. I wonder if Windows' IOCP API that was mentioned before in the parent thread wouldn't be able to handle both though. Windows' event concept seems more general than sockets or GUI events. However I don't know if this is actually how GUI events are handled in Windows.
You should talk to a Tcl/Tk user (if there are any left :-).
I used to be one of those :)
So tell us more about the user experience of having a standard event loop always available in the language, and threads, network I/O and GUI events all integrated. What worked, what didn't? What did you wish had been different? -- --Guido van Rossum (python.org/~guido)