[zeromq-dev] weird bug

john skaller skaller at users.sourceforge.net
Tue Mar 6 00:17:39 CET 2012

On 06/03/2012, at 5:10 AM, Stephen Lord wrote:
> With system calls such as epoll_wait, sendmsg and recvmsg, there are
> defined behaviors here. recvmsg will return EINTR if the signal is delivered
> before any data was available, on sendmsg it is only delivered before any
> data was sent.
> Because of these rules, system call restart is possible, however, with
> zmq_send() getting EINTR, I do not know if anything made it onto the
> socket or not or what to do with the zmq_msg_t structure.

It is a good point, so you would have to assume "the same" for 0MQ.
If 0MQ does not behave the same it is a bug.

The question here is what happens to a compound operation,
such as PUBlishing to multiple endpoints.

I think there are two options, and 0MQ reference manual should
explicitly state which one applies:

(a) no state changes at all, client may restart
   or abandon

(b) partial operation, client MUST restart
  (or abandon program)

Unfortunately (b) is inevitable for any non-atomic operation.

Retrying internally is NOT an option. If 0MQ did that
Ctrl-C would never kill a stuck process.  The decision
has to be left to the client (including a binding).

john skaller
skaller at users.sourceforge.net

More information about the zeromq-dev mailing list