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 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.
> I certainly wouldn't expect Linux to do well with that many user-level
> threads doing blocking IO, which is what you seem to be suggesting.
> None of the scalability test results I have seen for C10k problems
> support that.
When are the last such benchmarks you saw? NPTL is fine scheduling many
thousands of threads. And will usually beat a userspace scheduler
because it was (a) written by cycle-counting fanatics in kernelspace and
(b) knows all sorts of hardware information userspace doesn't.
I'll caution you before pulling out too many anecdotes and references:
most I/O-scalability material is hard-to-compare, old,
hardware/OS/protocol/problem specific, or otherwise apples-to-oranges.
It is very hard to get a conclusive story. Even the C10k site (and its
companions[2]) are mostly just buckets of subjective, often disagreeing
links.
I'm not trying to tell you there's One True Way. I'm trying to point out
that:
- Serial execution (do IO, make a decision, do more IO) matters. When
you give someone an async-only IO interface, they yell at you for
forcing callback-spaghetti on them. And/or makeshift something
"serial-ish" on top.
- Platform-IO-or-AIO-under-language-integrated-tasks is the
much-loved "Erlang model". Also the Go model (the one Ryan
Dahl fell in love with after spending years chastising anyone
who liked kernel threads. Even though on many platforms kernel
threads _beat_ user threads. Are you seeing a pattern? It's a
complicated territory.)
- 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.
- On _some_ platforms, _some_ of the time, it is likely that the
kernel engineers have taken the time to make their threads and
sync IO fast enough (or the integration we're trying to do running
in someone else's IO model requires) that it's sensible to map
"task" to "thread" and issue IO calls synchronously to the OS.
When this is true, we'll provide the option. When not, it should
be obvious.
> idea though as the lowest level; coding for AOI with IOCP or the likes
> of libev and libevent is nothing new, and hoarding address space so that
> buffers are only bound on demand when the IO can complete is quite
> normal - it seems to be moving in the wrong direction to have tasks
> running unless you can create a special type of callback task that has
> so little stack while idling at 'top level' that it is effectively just
> the in-use task state data.
"Tasks running"? They get descheduled when they issue IO. That's the point.
> I guess the question is whether it is a concrete ambition to be able to
> use Rust to implement server in the near term, and whether the
> efficiency will be in Rust or rely on specific aspects of (for example)
> some Linux versions.
It is a concrete ambition to be able to serve lots of connections on all
our target platforms, using tasks as a primary abstraction, if not the
sole abstraction.
> I guess the proof will be in the eating of the pudding. I'd very much
> like to experiment but like others I need Win32 and Win64 to work well
> (as well as Linux and FreeBSD).
I agree. I think measuring and tuning a working, usable implementation
with solid platform support will prove much more productive than
debating abstract design on a mailing list. Uv is (as far as I know) one
of a small number of libraries that does a nice job abstracting IOCP
_and_ kqueue _and_ epoll, so I remain confident that it's as good a
thing to build on as any.
-Graydon
[1] http://www.kegel.com/c10k.html
[2] http://nick-black.com/dankwiki/index.php/Network_servers
_______________________________________________
Rust-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/rust-dev
