[zeromq-dev] czmq / zloop / zmq_poll / timers

Pieter Hintjens ph at imatix.com
Mon May 23 20:53:43 CEST 2011

On Mon, May 23, 2011 at 7:45 PM, Kim Lester <kim at dfusion.com.au> wrote:

> One of my connections is a fd not a zmq socket  (recall zmq_pollitem_t can handle both).
> This would however mean amending zloop_reader to handle fd's OR a new function.

Coincidentally I hit exactly the same issue today.

> I suspect my preference would be to pass in a zmq_pollitem_t to the reader which would also impact zloop_start() a little and handle POLLOUT automagically I think.

Sounds good.

> I'd also like to suggest that rather than passing void *socket to the handler that it passes zmq_pollitem_t *...

Neat, I like it. Do fork the repo and send me a pull request, make
sure to update the test cases. I'm not worried about breaking the API
at this stage, it's in draft phase.

> Another option for timers (if one is using threads anyway) is to create a timer thread which can then send "tickless" events via a zmq socket to any other interested threads (without too much IPC delay hopefully). I may go down this path as it allows one to potentially add new timers at a shorter interval than the current timeout.
> The current reactor cannot AFAIK be interrupted nicely (I suppose I could send a signal :-( ) whereas by the very fact of having a socket that can receives "timer update" events (as well as timer expired events) means that the current timeout is interrupted by a POLLIN event and this can trigger timer set recalculations (additions/deletions etc)

Playing with threads and sending timer events is definitely doable,
and probably easy too. You can use a publisher that sends messages
with a certain frequency and varying header, and a subscriber filter
that defines which events it'll get, and thus the frequency. Every 1,
10, 100 etc. I forget the precise design, but you can work it out.

> As an aside IMHO it would be great if zmq_poll integrated timers like into zmq (rather like the linux specific timerfd_create()).
> because timers are so common/useful even if not strictly comms related.

Timers are pretty essential to any real 0MQ app, yes.

For 3.0, we're planning a separate utilities library (libzutil) that
would give language bindings additional functionality that's not in
libzmq. So far this has meant devices, SWAP, and other stuff being
removed from 3.0.


More information about the zeromq-dev mailing list