[zeromq-dev] adding timeout in zmq_poll

Pavel Gushcha pavimus at gmail.com
Mon Dec 28 11:14:01 CET 2009

2009/12/28 Martin Sustrik <sustrik at 250bpm.com>

> Hi Pavel,
>  I want to have timeout parameter in zmq_poll function. As i understood, It
>> is not very difficult to implement this. But i want to ask about underwater
>> stones:
>> 1) All oses support timeout parameter? in zmq.cpp i see one part of code
>> for windows, and one for other oses. Both parts have timeout parameter, but
>> for windows we can set timeout with microsecond granularity. We can't get
>> such granularity in linux?
> See Steven's discussion of the topic.

So the best solution is adding int timeout parameter to zmq_poll that mean
timeout in milliseconds?

>> 2) With adding timeout parameter in zmq_poll i must update bindings. I
>> looked at them and found, that binding for zmq_poll present only in
>> C,C++,Common Lisp bindings. May be i miss something?
> Nope. zmq_poll is not available from python & ruby yet.

I dont found zmq_poll binding for Java too.

> One more issue: poll function inside the zmq_poll function may return
> before there are any actual events (say if there are messages that are going
> to be filtered out) so note that it is called in a loop. Adding the timeout
> would mean that you have to measure time spent in each poll call and
> subtract it from the overall timeout time as passed to zmq_poll. The
> alternative would be not to guarantee any events on the return from
> zmq_poll.

If we adding timeout to polling, in any case there is possibility that no
one event was fired. Measuring spent time in each poll is too complicated
and high resolution measurement is hard portable (i'm not sure). Now
poll()/select() in many cases is called twice: first with zero timeout, and
second with -1/NULL timeout. I prefer to add custom timeout value in second
parameter, and this will guarantee, that zmq_poll() will not take no longer
time (with some error), than specified in timeout().

>  As i see, now zmq_poll is not optimized for polling big amount of sockets.
>> Is there plans to optimize this?
> In theory. In practice, each 0MQ socket is capable of handling thousands of
> connections thus actual pollset for zmq_poll will presumably contain just
> 2-3 sockets. Sophisticated poll algorithms may be actually less efficient in
> such a case.
> Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20091228/512c4df1/attachment.htm>

More information about the zeromq-dev mailing list