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

[Mark Adam]

On Fri, Oct 12, 2012 at 3:43 PM, Guido van Rossum <guido at python.org> wrote:
> 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.

Yes, however, as suggested in my other message, there are three
desires: {"cross-platform (OS) portability", "speed", "unified API"},
but you can only pick two.

One of these has to be sacrificed because there are users for all of those.

I think such a decision must be "deferred() "to some
"Future(Python4000)" in order to succeed at making  "Grand Unified
Theory" for hardware/OS/python synchronization.

(For the record, I do think it is possible, and indeed that is exactly
what I'm working on.   To make it work will require a compelling,
unified object model, forwarding the art of Computer Science...)

markj