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