template <typename Allocator = std::allocator<void> > class limits_service { ... };
template <typename Service> class basic_limits { public: basic_limits(demuxer_type& d); void post_queue(std::size_t value); std::size_t post_queue() const; ... and so on ... };
typedef basic_limits<limits_service<> > limits;
Usage:
boost::asio::demuxer d; boost::asio::limits l(d); l.post_queue(42);
I thought about this some more, and I think it might be better to pass the limits to the demuxer constructor. You have to forgive me. I'm pretty anal about memory management. I tend to allocate my memory at startup on Linux servers because of the way the OOM-killer works. I'm working on a patch to reactor_op_queue.hpp to pool as many of your internal data structures as possible. If I had the limits at construction, I could allocate the necessary internal structures when the demuxer is instantiated. I think this the right thing to do for server applications because if the admin configures a server to handle n number of connections I want to make my best attempt to handle those connections. If the system doesn't have enough resources I think the admin should know about it at startup. This allocation strategy should probably be policy based, because for clients allocating from the heap is more appropriate. I wrote a bit more about this a while back here: http://baus.net/memory-management Thanks again, Christopher