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