[zeromq-dev] Blocking when receiving multipart messages

[James Harvey]

Hi,

Yes the message is atomic and you can assume all parts are available immediately once the first part has arrived.

In general if I create anything that cares about blocking on the receive side I always end up using zmq_poll() and handle it that way. Part of the reason being it leaves it open in the future to handle input from another socket for signaling or whatever.

I have never used zmq_msg_more() (I didn’t even know it existed until now), I always use the socket option ZMQ_RCVMORE as in my poll loop I am working with the socket anyway.

James
From: zeromq-dev <zeromq-dev-bounces at lists.zeromq.org> On Behalf Of Al Grant
Sent: 08 August 2018 10:58
To: zeromq-dev at lists.zeromq.org
Subject: [zeromq-dev] Blocking when receiving multipart messages

I'm receiving multipart messages on a SUB socket and I want to make my
code non-blocking. The docs say that a multipart message is delivered
atomically. Can I read that as a guarantee that, if there is a 'more' indication
after a previous part, a zmq_recv() on the next part will never block but
immediately read the next part?

If I can rely on that guarantee then I only need to use ZMQ_DONTWAIT on
the first part, and once that succeeds I can read the whole multipart message
atomically without blocking. But that guarantee doesn't seem to be explicitly
stated in the docs.

Also, the docs for zmq_msg_recv() say:

An application that processes multi-part messages must use the ZMQ_RCVMOREzmq_getsockopt(3)<http://api.zeromq.org/3-3:zmq_getsockopt> option after calling zmq_msg_recv() to determine if there are further parts to receive.

Wouldn't it be simpler and more efficient to use zmq_msg_more()?

Al
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20180808/7cc36804/attachment.htm>