I don't think it makes much of a difference which API you use. When writing asynchronous I/O handlers, the basic structure is almost always the same:
1. fd becomes readable, 2. read() as much as possible, 3. process the available input, 4. write() the results you've computed, 5. return and wait until (1).
From my understanding, you're describing "reactive" event handling systems. In reactive systems, you get notified when I/O can be performed, then you go do it . In proactive, you initiate the operation (either read or write), and the OS notifies you when the operation has completed. I'm clarifying because when I see "async network io" I usually think of proactive models, rather than reactive models (I think the Linux asio library is a proactive model ...).
In fact, most of the application code I write for use with asynchronous I/O doesn't do any I/O _at all_. The handlers operate on memory buffers only ...
This is the level of abstraction that I hope makes it into a Boost networking (or general I/O multiplexing) library - the application code should be able to register a callback (e.g. using Boost function) that the multiplexor calls when an I/O operation completes.
I don't know. ;-) To me, when people talk about schedulers, demuxers, reactors, proactors, and whatnot else, it's all the same thing: it's an event loop that jumps into a bunch of callbacks.
That may be simplifying it a little bit too much - reactive and proactive models do differ significantly in a number of details (including interface semantics), although at the application callback level it might be best to abstract or hide those kind of details.
I don't feel strongly about the name to use for that. The term "scheduler' seemed to describe nicely what my class does, that's the only reason I picked it.
I've been using forms of the word "multiplexor" in work-related projects for a while, and I've seen it used here in the Boost list. I like it better than scheduler, which I've seen in many other contexts outside of what we're discussing. For those using ACE (or are familiar with the communication pattern terminology), the terms Reactor and Proactor immediately communicate a lot of information ... Cliff