Boost logo

Boost :

From: Peter Simons (simons_at_[hidden])
Date: 2005-08-11 03:38:00


Jose writes:

> I think a well thought out boost scheduler/multiplexor
> module is needed.

So do I. It would be very nice to have an I/O scheduler in
Boost. All that other networking stuff is just sugar
coating, IMHO. Personally, find working with read(),
write(), and plain plain file descriptors to be much simpler
than using any of those fancy iostream classes.

> I would just focus on async network io in linux
> (preferably using epoll).

I believe that a good API could hide the underlying
scheduling mechanism provided by the OS. A neat example
would be this library:

  http://www.monkey.org/~provos/libevent/

It's portable across various Unices and Windows, and does
provide a very clean abstraction of the thing we generally
know as poll().

> Networking is one area where boost should probably have
> separate platform solutions so that best performance and
> elegance are not compromised.

Although I agree that performance very important, it is my
experience that the percentage of time spent in the
scheduling parts of an I/O-bound application is rather
miniscule. It doesn't really matter whether you maintain
your poll() array with zero copies all the time, or whether
you use epoll(), /dev/poll, kqueue(), or select(). These
things may make a difference in benchmarks, but not in
real-life applications.

> On top of that, having an acceptor and connector
> implementation with basic http examples would go a long
> way towards advancing in the right direction.

No problem:

  http://cryp.to/mini-httpd/
  http://cryp.to/mini-httpd/mini-httpd-1.0.tar.gz

> If you plan to do this then I would gladly use it and
> provide feedback.

What I could definitely do is to get the source code I have
right now checked into the Boost sandbox under an
appropriate license, then we'll see where it goes from
there. ;-)

Peter


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