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 <[email protected]> On Behalf Of Al Grant Sent: 08 August 2018 10:58 To: [email protected] 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
_______________________________________________ zeromq-dev mailing list [email protected] https://lists.zeromq.org/mailman/listinfo/zeromq-dev
