Re: [boost] surveying async network io libraries

From: Cliff Green (cliffg_at_[hidden])
Date: 2005-08-12 18:30:27

> 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