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 _______________________________________________ libev mailing list [email protected] http://lists.schmorp.de/cgi-bin/mailman/listinfo/libev
