On Sat, Nov 12, 2011 at 13:16, Richard Smith <[email protected]>wrote:
> Hi, > > 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 > > http://gist.github.com/1361080 > > 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 .... > I am pretty sure this is a bug, and a very serious one - if POLLIN is set, there should be a message waiting for recv, but there isn't one. Further, you can actually make messages arrive (on ROUTERs) that shouldn't by adding extra connections. I reported this earlier in the week as part of LIBZMQ-280 <https://zeromq.jira.com/browse/LIBZMQ-280> on Jira. It affects ROUTER/DEALER as well as REP. -MinRK > > > Regards, > > Richard > > > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev > >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
