Re: [boost] asio queue OOM stress test -- Windows deadlock

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:
http://baus.net/memory-management

Thanks again,

Christopher