[zeromq-dev] Possible bug in ZMQ3.1 with REP/REQ socket polling

Richard Smith rsmith at rsbatechnology.co.uk
Sat Nov 12 22:16:23 CET 2011


I am the maintainer of the Haxe 0MQ binding (http://github.com/rjsmith/hxzmq)
and I am currently adding experimental 0MQ 3.1 support ( I am going to skip
3.0).  All but one of my 49 unit tests are now passing. But  I have found
an issue with the 0MQ 3.1 zmq_poll method call indicating the readiness of
a brand new REP socket to be read from (by setting the revents array flag
for the REP socket), even though no messages have been sent to it from the
similarly brand-new REQ socket to which it is connected.  In 0MQ 2.1.10,
the same code doesn't exhibit this behaviour (ie the zmq_poll call does not
indicate any non-blocking read / write state for the REP socket, which is
what I would expect).

I have also found that:
1. The behaviour is only for ipc and tcp (I havent tested with pgm).
 inproc is OK (REP socket not flagged as readable)
2. This only seems to an issue for REP sockets.  Other tests I have done
for PUB/SUB and PAIR/PAIR connections do not show this behaviour in ZMQ 3.1
3. I have also noticed that a zmq_poll done immediately after sending a
message on the REQ socket shows that the REQ socket has something waiting
to be read.

I have added a Haxe code snippet here that shows the series of 0MQ calls
using the hxzmq binding library


I am not that familiar with native C compilation (I cheat and use the hxcpp
haxe compiler for building all my 0MQ haxe code!) so havent yet tried to
reproduce with a C language example.

I thought I'd raise this to the group in case I have found a hitherto
unknown 3.1 "feature".  Or I missed it in the documentation / mailing
lists!  Happy to help track this down ....


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20111112/b15e4f38/attachment.htm>

More information about the zeromq-dev mailing list