I believe multipart messages are treated atomically, which means if you're able to receive the first part then you're able to receive all the remaining parts immediately. When QZmq was first written I was not aware of the atomic handling, and so the code is probably more complex than it needs to be. On Sat, Apr 30, 2016, at 11:45 PM, Kalle Huttunen wrote: > Hi, thanks for your answer. The README of your QZmq project rises up > an interesting point: multipart messages. How do they work in relation > to ZMQ_FD? When the FD signals read, have all message parts been > received? > > -- > Kalle Huttunen > > la 30. huhtikuuta 2016 klo 23.16 Justin Karneges <jus...@affinix.com> > kirjoitti: >> __ >> Expanding on your first point: the file descriptor only triggers read >> notifications, and the notification means to query ZMQ_EVENTS. For >> example, when a zmq socket becomes writable, the ZMQ_FD file >> descriptor becomes readable, and you react to that by checking >> ZMQ_EVENTS and discover the zmq socket can be written to. >> >> Also you may be interested in https://github.com/jkarneges/qzmq >> >> On Sat, Apr 30, 2016, at 12:32 PM, Kalle Huttunen wrote: >>> The ZeroMQ FAQ (http://zeromq.org/area:faq#toc5) states in the "Why >>> can't I use standard I/O multiplexing functions such as select() or >>> poll() on ZeroMQ sockets?" question: >>> >>> > Note that there's a way to retrieve a file descriptor from ZeroMQ >>> > socket (ZMQ_FD socket option) that you can poll on from version >>> > 2.1 onwards, however, there are some serious caveats when using >>> > it. Check the documentation carefully before using this feature. >>> >>> I've prototyped integrating ZeroMQ socket receiving to Qt's and >>> custom select() based event loops, and on the first glance >>> everything seems to work. >>> >>> From the documentation I have identified two "caveats" that I handle >>> in my code: >>> >>> 1. The ability to read from the returned file descriptor does not >>> necessarily indicate that messages are available to be read from >>> the socket >>> >>> This I have solved by checking ZMQ_EVENTS before reading from the >>> socket. >>> >>> 2. Events are signaled in edge-triggered fashion >>> >>> This one I have solved by always receiving all the messages from the >>> socket when the file descriptor signals. >>> >>> Are there some caveats that I'm missing? >>> >>> -- >>> Kalle Huttunen >>> _________________________________________________ >>> zeromq-dev mailing list >>> zeromq-dev@lists.zeromq.org >>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev >> >> _______________________________________________ >> zeromq-dev mailing list >> zeromq-dev@lists.zeromq.org >> http://lists.zeromq.org/mailman/listinfo/zeromq-dev > _________________________________________________ > zeromq-dev mailing list > zeromq-dev@lists.zeromq.org > http://lists.zeromq.org/mailman/listinfo/zeromq-dev
_______________________________________________ zeromq-dev mailing list zeromq-dev@lists.zeromq.org http://lists.zeromq.org/mailman/listinfo/zeromq-dev
