[Python-ideas] non-blocking buffered I/O

[Guido van Rossum]

On Mon, Oct 29, 2012 at 4:12 PM, Steve Dower <Steve.Dower at microsoft.com> wrote:
> Guido van Rossum wrote:
>>
>>> By the way I don't know how this whole approach (of mocking
>>> socket-like or file-like objects with coroutine-y read() / readline()
>>> methods) lends itself to plugging into Windows' IOCP.
>>
>> Me neither. I hope Steve Dower can tell us.
>
> I suppose since my name has been invoked I ought to comment, though Richard (Oudkerk, I think?) seems to have more experience with IOCP than I do.

Aha, somehow I thought Richard was a Mac expert. :-(

> From my point of view, IOCP fits in very well provided the callbacks (which will run in the IOCP thread pool) are only used to unblock tasks. Yes, it then will not be a pure single-threaded model, but on the other hand it isn't going to use an unbounded number of threads. There are alternatives to IOCP, but they will require expert hands to make them efficient under scale - IOCP has already had the expect hands applied (I assume... maybe it was written by an intern? I really don't know).

Experts all point in its direction, so I believe IOCP is solid.

> The whole blocking coroutine model works really well with callback-based unblocks (whether they call Future.set_result or unblock_task), so I don't think there's anything to worry about here. Compatibility-wise, it should be easy to make programs portable, and since we can have completely separate implementations for Linux/Mac/Windows it will be possible to get good, if not excellent, performance out of each.

Right. Did you see my call_in_thread() yet?
http://code.google.com/p/tulip/source/browse/scheduling.py#210
http://code.google.com/p/tulip/source/browse/polling.py#481

> What will make a difference is the ready vs. complete notifications - most async Windows APIs will signal when they are complete (for example, the data has been read from the file) unlike many (most? All?) Linux APIs that signal when they are ready. It is possible to wrap this difference up by making all APIs notify on completion, and if we don't do this then user code may be less portable, which I'd hate to see. It doesn't directly relate to IOCP, but it is an important consideration for good cross-platform libraries.

I wonder if this could be done by varying the transports by platform?
Not too many people are going to write new transports -- there just
aren't that many options. And those that do might be doing something
platform-specific anyway. It shouldn't be that hard to come up with a
transport abstraction that lets protocol implementations work
regardless of whether it's a UNIX style transport or a Windows style
transport. UNIX systems with IOCP support could use those too.

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