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

[Pieter Hintjens]

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.

-Pieter