Boost logo

Boost :

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

   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

-T.J. Purtell

Boost list run by bdawes at, gregod at, cpdaniel at, john at