Boost logo

Boost :

From: Bardur Arantsson (spam_at_[hidden])
Date: 2005-12-16 18:25:27


christopher baus wrote:
>>template <typename Allocator = std::allocator<void> >
[--snip--]
> 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

You're allocating + forcing initialization of memory at startup, yes?

As I understand it, the Linux OOM killer may *still* kill your
application even if your application is "well behaved" (in the sense
that it isn't actually responsible for the allocation that causes the
OOM condition). It certainly doesn't always pick the application that
caused the allocation failure.

The only reasonable thing to do is to turn off overcommit, or to add
lots of swap and *pray* that your working set isn't larger than your
physical memory.

Cheers,

-- 
Bardur Arantsson
<bardurREMOVE_at_[hidden]>
<bardurREMOVE_at_[hidden]>
Sticks and stones may break my bones, but hollow-points expand on
impact.

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk