On Thu, May 12, 2011 at 9:56 AM, Martin Sustrik <sust...@250bpm.com> wrote:
> On 05/09/2011 02:41 PM, Paul Colomiets wrote: > > Well, I have no practical experience, but a lot of alloc_assert's in the >> code says that it will be aborted. BTW, it will be so not only if >> overcommit_memory is set right, but also if ulimit is set for the >> application's memory. Which is awfully bad IMO. >> > > What else would you do if you run out of memory? Any recovery mechanism in > user space is likely to fail because there's no memory available :) Killing > (and possibly restarting) the app seems like a reasonable option to me. On the application side you can flush buffers, flush cache, close connections. On zeromq side you can stop accepting connections, stop processing incoming data, drop incoming messages, drop messages already in queue (delivery is not reliable anyway), wait (for data to be processed), notify user about memory failure. Enought? For some applications it's crucial, e.g. for databases which has a write cache, for persistent queues which postpone their writes, for game servers having some state in memory, whatever. You right that it's reasonable for some *applications*. But it's quite mad for networking library. It will be fixed in kernel implementation anyway (may be using other methods). Still I'm pretty sure it should be fixed in a library.
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
