Boost logo

Boost :

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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk