On Oct 20, 2012, at 4:53 PM, Guido van Rossum <guido at python.org
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
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.)