On 11 Aug 2005 10:38:00 +0200, Peter Simons <simons@cryp.to> 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