[zeromq-dev] [PATCH] Fixed OOM handling while writing to a pipe
Martin Sustrik
sustrik at 250bpm.com
Sat May 21 08:26:29 CEST 2011
Hi Paul,
> What assertions? If send fails we should revert the state to what it
> was before send() was called. That shouldn't trigger any assert.
>
> e.g. lb.cpp:118
> your code expects pipe->write never fail after first message. I would
> improve that, you just said you want small incremental steps, and this
> patch really fixed crash in one of my test scripts.
Ok. I see.
> Well, I usually do something like:
>
> rc = zmq_send(&msg, ZMQ_SNDMORE);
> if(rc) return false;
> rc = zmq_send(&msg2, 0);
> assert(!rc);
> Because previously sending all subsequent message parts could never fail.
Ack.
> One additional issue: If you change function prototype to return
> error, you should check the error at each place the function is
> called from.
>
>
> Sure. Am I missed something?
ypipe::write is called from at least one more place,
zmq::writer_t::terminate, the error value should be checked there as well.
> All in all, I'll fix the patch, if we decide it's needed at all
> (discussion is in another thread).
Well, the codebase can be improved to attempt for recovery from OOM.
This could be possibly useful in the async part of 0MQ (if there's not
enough memory to handle a connection, close it), however, I am not sure
whaether it's possible to make that work in practice, say in case od
DoS-ing a socket with unreasonable amount of connections.
In the sync part, ENOMEM can be returned to the app, but still, it's
just getting rid of responsibility and passing it to the app. There's
nothing much the app can do in case of ENOMEM other than to assert. It
can try to shut down 0MQ sockets/context, however, the shutdown itself
is likely to fail due to OOM.
Martin
More information about the zeromq-dev
mailing list