[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