[zeromq-dev] adding timeout in zmq_poll
sustrik at 250bpm.com
Mon Dec 28 11:25:25 CET 2009
Pavel Gushcha wrote:
> 2009/12/28 Martin Sustrik <sustrik at 250bpm.com <mailto: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?
Milliseconds is the least common denominator. However, I would suggest
using microseconds or nanoseconds in the API even though the underlying
infrastructure is not able to support that kind of precission. The point
is that precise timers would arrive ultimately and at that point we
would be able to use them without modifying 0MQ API.
> 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.
Right. No zmq_poll for Java either. In case you need it, feel free to
add it. It should be quite straightforward.
> 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().
More information about the zeromq-dev