[zeromq-dev] Implementing efficient recv timeouts [was Re: zmq::poll timeout returns immediately on MacOS/X 10.5]

Martin Sustrik sustrik at 250bpm.com
Fri Jun 11 21:36:02 CEST 2010

Chuck Remes wrote:

>> What's really difficult is that there's no cross-platform 
>> thread-friendly highly-efficient timer mechanism.
> Does it help timer performance if the timeout resolution is coarse
> like milliseconds? I can imagine in some very high frequency scenario
> where someone might want a timer that expires in as little as 1
> millisecond, but I can't think of reasonable cases for usec or
> nanosec timer resolution.

Let me give some more detail:

zmq_socket::recv is currently waiting for incoming messages by doing 
POSIX recv (on a internal fd connecting it to different threads).

recv doesn't have timeout parameter, so what has to be done is first to 
select/poll on a pollset containing a single fd (select & poll do have 
timeout parameter), then either report the timeout or do the recv.

This would cause some performance degradation.

However, what's worse is that fd may signal even in a case where no 
message arrives (in case an internal event happens, such as 
establishment of connection or similar).

In such case there's no message to return and we have to wait further. 
However, the waiting time should be decreased as some of it already 
elapsed. Thus we have to measure exact time before calling select/poll...

All in all, the performance impact looks considerable.


More information about the zeromq-dev mailing list