[Python-ideas] The async API of the future: Reactors

[Guido van Rossum]

[Responding to a different message that also pertains to the reactors thread]

On Thu, Oct 11, 2012 at 6:38 PM, Mark Adam <dreamingforward at gmail.com> wrote:
> 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)