[zeromq-dev] ZMQ_POLLIN received on WRITE event

KIU Shueng Chuan nixchuan at gmail.com
Fri Sep 26 02:05:40 CEST 2014

Your code could be stripped down a lot:
1) PUB socket is only for sending. There's no need to test it for
2) PUB socket never blocks when sending. There's no need to test it for
3) SUB socket is only for receiving. There's no need to test it for
4) The ZMQ_FDs are only to be tested for readability. They are NOT to be
tested for writability (and in fact should always test positive for

On Thu, Sep 25, 2014 at 5:09 PM, Dorvin <dorvin at tlen.pl> wrote:

> Thank you for your replies so far. I'll clarify if it does matter that
> I'm using Windows and libzmq 4.0.4.
> W dniu 2014-09-25 04:38, Goswin von Brederlow pisze:
> >the ØMQ library
> >      shall signal any pending events on the socket in an edge-triggered
> >      fashion by making the file descriptor become ready for reading.
> This is exactly what bothers me. According to documentation I'm supposed
> to get most socket events when FD gets ready for reading.
> But when I do:
> sel_ret = select(sub_fd + 1, &sub_set, NULL, NULL, &time );
> if (sel_ret == 1)
> {
>      zmq_getsockopt(subscriber, ZMQ_EVENTS, &zevents, &zevents_len);
>      if(zevents & ZMQ_POLLIN)
>      {
>          //retrieve and do something with message
>      }
> }
> I receive only some or none messages at all. You may see it in testcase.
> For now I found 3 options to work this out:
> 1. Use zmq_poll() periodically - this seems to get read and write
> notifications at the same time and therefore not lose events. This does
> not look like event-driven way of doing things, though.
> 2. Use getsockopt with ZMQ_EVENTS after each send or receive - this is
> like small version of zmq_poll invoked almost constantly.
> 3. Keeping write notifier active all time which is not a good idea
> because it fires on every pass of event loop. In first reply I already
> was discouraged from this option.
> If you would be so kind I would ask you to execute my code, see results
> and tell me if it's expected behavior (some kind of optimization or
> something), I miss something in how 0mq sockets should work, or if I
> should file bug report.
> You may remove line "if (occurences > 0) {break;};" to see that what I
> describe is not single event but it repeats.
> With regards,
> Jarek
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20140926/4469fbb2/attachment.htm>

More information about the zeromq-dev mailing list