[Python-ideas] The async API of the future

[Guido van Rossum]

On Mon, Nov 5, 2012 at 6:19 AM, Sturla Molden <sturla at molden.no> wrote:
> My main problem with IOCP is that they provide the "wrong" signal. They tell
> us when I/O is completed. But then the work is already done, and how did we
> know when to start?
>
> The asynch i/o in select, poll, epoll, kqueue, /dev/poll, etc. do the
> opposite. They inform us when to start an i/o task, which makes more sense
> to me at least.
>
> Typically, programs that use IOCP must invent their own means of signalling
> "i/o ready to start", which might kill any advantage of using IOCPs over
> simpler means (e.g. blocking i/o).

This sounds like you are thoroughly used to the UNIX way and don't
appreciate how odd that feels to someone first learning about it
(after having used blocking I/O, perhaps in threads for years).

>From that perspective, the Windows model is actually easier to grasp
than the UNIX model, because it is more similar to the synchronous
model: in the synchronous model, you say e.g. "fetch the next 32
bytes"; in the async model you say, "start fetching the next 32 bytes
and tell me when you've got them".

Whereas in the select()-based model, you have to change your code to
say "tell me when I can fetch some more bytes without blocking" and
when you are told you have to fetch *some* bytes" but you may not get
all 32 bytes, and it is even possible that the signal was an outright
lie, so you have to build a loop around this until you actually have
gotten 32 bytes. Same if instead of 32 bytes you want the next line --
select() and friends don't tell you whether you can read a whole line,
just when at least one more byte is ready.

So it's all a matter of perspective, and there is nothing "wrong" with
IOCP. Note, I don't think there is anything wrong with the select()
model either -- they're just different but equally valid models of the
world, that cause you to structure your code vastly different. Like
wave vs. particle, almost.

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