Boost logo

Boost :

From: christopher baus (christopher_at_[hidden])
Date: 2005-12-16 16:05:24

> 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:

Thanks again,


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