[Python-ideas] The async API of the future

[Glyph]

On Oct 20, 2012, at 4:53 PM, Guido van Rossum <guido at python.org> wrote:

> On Sat, Oct 20, 2012 at 4:41 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>> The point is that, with a completion-based model, you need a function
>> or method for every possible system call that you might want to perform
>> asynchronously.
> 
> TBH, I like APIs that wrap all system calls. System calls have too
> many low-level details that you have to be aware of, and they too
> often vary per platform. (I just wrote a simple event loop plus
> scheduler along the lines of your essay, extending it to the point
> where I could do basic, fully-async, HTTP exchanges. The number of
> details I had to take care of was excruciating; and then there were
> the subtle differences between OSX and Ubuntu.)

The layer that wraps the system calls does not necessarily be visible to applications.  You absolutely need the syscalls to be exposed directly at some lower, non-standardized level, because it takes on average 15 years to shake out all the differences between platform behavior that you observed here :-).  If applications try to do this, they will always get it wrong, and besides, they want to be making different syscalls for different transports.

Much of Twisted's development has been about discovering exciting new behaviors on new platforms or new versions of supported platforms in the face of new levels of load, concurrency, or some other attribute.

A minor nitpick: system calls aren't usually be performed asynchronously; you execute the syscall non-blockingly, and then you complete the action asynchronously.  The whole idea of asynchronous I/O via non-blocking APIs implies some level of syscall wrapping.)

-glyph

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20121020/38e709bb/attachment.html>