ev_periodic like functionality for time intervals

Thilo Schulz thilo at tjps.eu
Sat May 23 17:57:58 CEST 2015


On Friday 22 May 2015 09:49:00 Marc Lehmann wrote:
> No, this suggestion was really only having one ev_timer, and checking for
> interval crossings inside, you wouldn't have an extra ev_periodic watcher:

Well, but then I would have only about a minute-precision (or depending on how 
often I fire the ev_timer) even for the normal use case where time jumps 
usually don't happen.
Obviously I don't want that, so I'd still need a periodic, or alternatively a 
second timer.

> Yes, it really isn't documented, and it wasn't on my mind when I designed
> it, but it turns out to work that way and I can say I am rather pleased
> that the design of libev lends itself to a reasonably clean solution.

Yes, I've tested it. The reschedule part works fine and it does exactly what I 
want it to do. It really is a nice solution, and it fixes several other 
problems as well.
For instance, ugly stuff like time zone changes and leap seconds as returned by 
localtime_r() can be handled from the reschedule callback as well.

Still, there is one thing that is a bit "unschön" (for lack of a better word).
Currently, there is no way to tell why the rescheduling function was called. 
Whether it was a time jump, or whether the periodics watcher is about to be 
invoked.

So for the * marked state changes from your example:

##
current state    state indicated by "now"  return value
off              off                       next 10:00
*off              on                        now
*on               off                       now
on               on                        next 22:00
##

the reschedule callback will not be able to distinguish between "time jump" or 
"regular invocation", and in the latter case, which will by far be the most 
regular use case, the periodic callback is going to be invoked twice 
unnecessarily.

> The reschedule_cb WAS meant to be called at internal undocumented points
> in time, it was NOT meant as a "potential time jump indicator" (mostly for
> lack of prior art to me, as this periodic thing seems to be quite uniqaue
> to libev, and lack of usage example).
> 
> However, I do think that documenting the reschedule callback as such a
> hook (among other things) is probably the right thing.
> 
> We are in the process of discussing on how to formalise this in the
> documentation, which is likely a bit difficult.

Hmm. The documentation hints at it, but isn't very definite about it so if I 
may make a few suggestions, taking into account the experiences I collected 
the last few days:

- Make clear that the reschedule_cb is going to be called before the periodics
  watcher is being invoked
- The reschedule_cb may be invoked by libev() at arbitrary other points in
  time

To address the "Unschönheit" mentioned by me:
- Make the periodics watcher pending before calling the reschedule callback.

> A timer of sorts, but not an ev_timer: libev checks for timejumps on every
> iteration and simply limits itself to sleep no more than MAX_BLOCKTIME
> (59.743s).

Thanks for laying this out to me.

-- 
Best regards,
Thilo Schulz



More information about the libev mailing list