Re: [boost] surveying async network io libraries

From: Peter Simons (simons_at_[hidden])
Date: 2005-08-12 11:30:01

Jose writes:

 >> Personally, find working with read(), write(), and plain
 >> plain file descriptors to be much simpler than using any of
 >> those fancy iostream classes.
 >
 > I'd like to see a pros/cons comparison of both approaches.

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).

So (usually) there are exactly two places where you do I/O -- as
opposed to synchronous I/O where you read some value, process it,
read some other value, process that, etc. On those two occasions
where I actually _do_ I/O, it doesn't matter whether I type
"write(fd, buf, len)" or "ostream.write(buf, len)".

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, so that the underlying I/O code
can be generic. The FastCGI library is a nice example for that;
it is completely independent of the underlying I/O driver. You
can use it synchronously or asynchronously, it doesn't matter.

 >> http://www.monkey.org/~provos/libevent/
 >
 > But this is a C library, isn't it ?

Yes, libevent isn't an ideal I/O driver for C++ programs. I just
think it demonstrates nicely that with nothing more than the
functions

     struct event;
     void   event_set(struct event *ev, int fd, short event,
                      void (*fn)(int, short, void *), void *arg);
     int    event_add(struct event *ev, struct timeval *tv);
     int    event_del(struct event *ev);
     int    event_dispatch();

..., you can write full-blown asynchronous I/O servers, and
they'll run on both Unix and Windows. Plus, there is a very
obvious translation of that API into C++.

Now, given how _simple_ that programmer interface is, I can't
help but wonder why other libraries need dozens of classes,
templates, and helper functions to do the same job.

 > Shouldn't the scheduler be renamed "reactor" ?

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. 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.

Peter