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@moka5.com