Boost logo

Boost :

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.

> 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

     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.


Boost list run by bdawes at, gregod at, cpdaniel at, john at