[zeromq-dev] zmq_poll not waiting for timeout if a socket is coming up

Brian Granger ellisonbg at gmail.com
Fri Sep 3 20:35:58 CEST 2010


On Fri, Sep 3, 2010 at 3:51 AM, Martin Lucina <mato at kotelna.sk> wrote:
> sustrik at 250bpm.com said:
>> > Is this a bug?  What should poll do with a socket that is still connecting?
>>
>> No, it's not a bug. The first events you see are actually some internal
>> messages from I/O thread managing the connecting to your application
>> thread. What timeout you set doesn't matter, because your application
>> cannot obviously process those internal messages while it is sleeping.
>
> Well, it's leakage of 0MQ internal events into the zmq_poll () API, so I'd
> call it a bug in the zmq_poll () implementation.

I am leaning towards this thinking as well.  Minimally, if the current
behavior is kept, we should update the docs to be clear about this
behavior.

>> If you use infinite timeout, 0MQ will hide these internal events from you.
>>
>> The problem with non-infinite timeout is that zmq_poll would have to
>> call gettimeofday each time it is called, so that in case of internal
>> event it would be able to compute the remaining time to wait. This would
>> have an impact on performance. (Actual impact wasn't measured yet. It
>> will differe between OSes depending on how efficiently is gettimeofday
>> implemented.)
>>
>> May thinking ATM is that in 2.1 this gettimeofday stuff should be done
>> in zmq_poll -- thus making it honour timeouts.
>
> +1 and I've been meaning to do this for 2.1 when I rewrote the zmq_poll ()
> code there, just haven't had time to do so yet.

+1

Do you want me to add an issue on github for this?

Thanks!

Brian

>> Those that are interested in extreme performance would still be able to
>> use ZMQ_FD and ZMQ_EVENTS socket options combined with native poll
>> functions.
>
> How would that get you better performance? You'd still have to deal with
> the case where ZMQ_FD would become ready and ZMQ_EVENTS would return
> nothing due to an internal 0MQ event being triggered.
>
> -mato
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com



More information about the zeromq-dev mailing list