[boost] boost asio in boost-trunk

From: tj (tj_at_[hidden])
Date: 2007-10-10 20:27:01

Hi,
   I've been using the latest boost asio on Mac OS X and I have fixes  
for two problems.

Problem #1
boost::asio::error::system_category is initialized to a null  
reference.  Since asio is a header only solution, the constant  
message table reference in the asio namespace must be initialized by  
with the value returned by the singleton  
boost::system::get_system_category rather than directly making a  
reference to the boost::system::system_message global.

Problem #2
In situations where there are a large number of open file descriptors  
the interrupter_ member of kqueue_reactor can end up  
'uninitialized.'  An exception needs to expose the failure case when  
pipe_select_interrupter can not be initialized.  The specific case I  
discovered this from was running 200 threads where each thread  
resolves a name, connects to a tcp port, and does a simple textrpc.   
A lot of file handles are opened in this case.

- Each thread has an io_service, and hence a kqueue fd
- Each thread has a tcp socket, and hence a socket fd
- Each thread resolves names, so there is a second backend io_service  
for the resolver, and hence another kqueue fd.
- Each kqueue fd is accompanied by a pair of pipe fds used to  
interrupt long running kevent calls.  Two kqueue fds means 4 pipe fds.

Overall, each thread running a simple tcp connection requires 7 fds.   
An implementor of code built on asio would try to minimize the number  
of io_services and use thread pools to dispatch work, but the code  
still needs to fail in a nice way.

I like the abstraction, thanks for all the great work.  A patch is  
attached.

-T.J. Purtell
tj_at_[hidden]