Re: [boost] surveying async network io libraries

From: Jose (jmalv04_at_[hidden])
Date: 2005-08-11 09:14:07

On 11 Aug 2005 10:38:00 +0200, Peter Simons <simons_at_[hidden]> wrote:
> 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'd like to see a pros/cons comparison of both approaches. I don't
have enough experience to comment on this. Maybe this is a case were
both approaches should be provided.
 
> 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().
 
But this is a C library, isn't it ? 

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

My understanding is that many boost users are looking for the best
performance and are building server apps where it could matter. I am
looking for best raw performance without having to use C
 
> 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. ;-)

Shouldn't the scheduler be renamed "reactor" ?

Also,  I have the impression that many people would develop web apps
in C++ if there was a basic set of libraries that make the job
feasible, so in that sense the reactor pattern and your FastCGI C++
make a nice couple.

I think there are three levels of demand for a boost networking library

1) reactor --> for users wanting to develop network apps
2) fastcgi --> for users wanting to develop web apps interfacing with
existing web servers
3) other --> for users wanting to develop very complex network apps
where more abstractions are needed (combining reactor, threads, ...)

Your library would fit levels 1 and 2 and the other libraries might be
more appropiate for 3