On Fri, May 20, 2011 at 12:21 PM, Martin Sustrik <[email protected]> wrote:
> There's one important point to be made: 0MQ currently behaves 100% > predictably in OOM condition -- it terminates the process. User is then > free to restart the process or take whatever emergency measures are > necessary. > > Any patches to OOM handling should preseve this 100% predictability. > zmq_send() can return ENOMEM instead of terminating the process, > however, it must do so consistently. Introducing undefined behaviour > under OOM conditions is not an option. Sorry to say this rather late, but before we change the behavior of 0MQ under OOM conditions, I'd want the consensus of users here. It is a radical change in semantics to go from asserting, to continuing with an error response. We cannot make such changes without being certain there is a consensus of approval for them. My own experience goes strongly against handling OOM in any way except assertion. We explored this quite exhaustively in OpenAMQ and found that returning errors in case of OOM was very fragile. It is not even clear that an application can deal with such errors sanely, since many system calls will themselves fail if memory is exhausted. We tried hard to make this work, and in the end had to choose for "assert" as the only robust answer. It's particularly important for services because most of the time there is a problem that must be raised and resolved, whether it's the too-low default VM size, or the lack of HWMs on queues, or too-slow subscribers, etc. The only exception to assertion, afaics, is for allocation requests that are clearly unreasonable. And even then, assertion seems the right response if these requests are internal. If they're driven by user data (i.e. someone sending a 4GB message to a service), the correct response is detecting over-sized messages and discarding them (and we have this code in 2.2 and 3.0). tl,dr - +1 for asserting on OOM, -1 for returning ENOMEM. -Pieter _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
