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

[Guido van Rossum]

On Fri, Oct 12, 2012 at 5:58 PM, Mark Adam <dreamingforward at gmail.com> wrote:
> 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.

Do you have any proof for that claim?

> 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...)

That would be the topic for a new thread, please.

-- 
--Guido van Rossum (python.org/~guido)