[zeromq-dev] non blocking receive and api_thread_poll_rate

Martin Sustrik sustrik at fastmq.com
Wed Jul 29 11:43:28 CEST 2009


Hi Jon,

> I'm very glad I've just picked up this thread, because I was considering 
> coding up an api thread with an almost identical while loop around a 
> non -blocking read (actually it needs to oscillate between blocking and non- 
> blocking as it actually running some timers)
> 
> However I did wonder whether there would be any interest in making the
> recieve call take an additional argument for a time out so that the
> user would not have to code up the loop.

The timeout argument would be nice, however, it's non-trivial to implement.

Currently, blocking on receive is done using a mutex (or a semaphore, or 
an event, depending on the platform). These operations have no timeouts :(

So, there are several workarounds to deal with the problem:

1. You can modify the code so that receive waits using poll (select, 
epoll, whatever) instead of a mutex. That'll allow you to use timeouts 
(1ms precision IIRC). Keep in mind though that waking up from poll is 
several microseconds slower then unlocking the mutex.

2. Create a dedicated timer thread that's unlock the mutex when the 
timer expires. In this case you'll have to register your timeout with 
the timer thread in each receive invocation. This would be rather slow 
as it requires synchronisation between your application thread and timer 
thread.

...etc...

In all cases it's a trade-off between functionality (timeouts) and 
performance (lower latency).

Thoughts?
Martin



More information about the zeromq-dev mailing list