On 29/04/2013 20:40, Graydon Hoare wrote:
On 13-04-28 12:05 PM, james wrote:
>Well, the issue is whether the program logic that will deal with data
>calls (say) read and iterates over the response, or whether something
>gets data and invokes a callback, in which case the code that deals with
>the data only has a thread (or stack if you want) while it is handling
>the data, and must explicitly store its state while waiting for more
>data. I'm loath to use 'actor' or 'task' because its just a state
>machine and as a C++ programmer I'd normally think that way.
What do you call it when the program calls read, this issues an AIO call
to an abstraction library like uv, the calling task is descheduled in
userspace and woken up when the data is ready (and this_might_ be
processed either synchronously or asynchronously depending on platform
mapping)?
This is what I call blocking synchronous read, a 'pull' model. Its
hardly different
from a threaded rogram with a userspace switch and sync to async call
translation,
whether N:1 or N:M. Granted that the compiler support for task switch
points and
segmented stack make the tasks more lightweight.
This is what we're looking at providing. Because it is the mental model
most people want, with a layer of indirection to permit mapping nicely
to whatever's fastest an most conveniently integrated with a given
platform/event loop.
It may well be what most people want most of the time, but history is so
far unkind
to N:M threading, and people used to writing highly scalable servers (a
minority,
perhaps) are used to thinking in terms of event processing.
I'm not suggestion that AIO should be the One True Way: I _am_
disappointed that
since it appears fundamental under the hood, it seems to be 'just' an
under-the-hood
artifact, and not the core user-facing technology for high-performance
use, at least as
far as discussion on the list is concerned.
- If our tasking library is built atop uv/glib/qevent/etc for AIO,
it'll_naturally_ expose abstract AIO-issue-and-wait operations.
Nobody's talking about_suppressing_ that, just providing a serial
lightweight-tasks-on-top I/O model.
The design focus would appear to on synchronous semantics. I would
prefer async
and an easy way to chain things together and wait with a future. I
would at least ask
that the lower level API not be second-class citizen.
I do not share your confidence in kernel engineers I'm afraid. We're
talking about
the same people who spent (as long as I can remember and longer still) with
significant issues relating to what 'fsync' should actually do (and
whether it
should be safe-to-platter by default, or whether adding layers in the IO
stack
should disable one's ability to be safe-to-platter). We'll see, I
guess, it certainly
doesn't harm if some platforms micro-optimise in a way that is helpful.
James
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
