[systemd-devel] [PATCH v2 00/26] Initial DHCP v4 library implementation

[Lennart Poettering]

On Mon, 09.12.13 23:41, Patrik Flykt (Patrik.Flykt at linux.intel.com) wrote:

> 
> On Mon, 2013-11-25 at 23:52 +0100, Lennart Poettering wrote:
> > Of course, timer callbacks should only be called once, ence
> > ONESHOT mode is the default -- unless you change that explicitly.
> > 
> > If this doesn't solve the issue, I wouldn't be surprised if there was
> > still a bug lurking with the sd-event code. Note that I fixed a bug
> > like this last week, did you check with currentl git of sd-event if
> > the issue persists?
> 
> Found the source of this issue. When the (monotonic) timeout function is
> called with time 0 meaning "immediately", the callback indeed gets
> called next by the event loop. But the uint64_t usec value passed to the
> timer callback is the value 0 set by the caller, not the current
> monotonic time the callback is called at. 

Yes, this is intended that way, so that for periodic usecases dispatch
latencies don't add up. Of course, in your case having the actual time
around is much more desirable.

> Using the supplied usec value,
> which is 0, as a base when calculating the next event timeout results of
> course in a time very much smaller time than the current monotonic time,
> causing the callback to be called immediately again. The value is again
> the one set by the caller and thus the calculated time is again too low.
> Rinse and repeat.
> 
> I fixed the problem by using sd_event_get_now_monotonic() instead of the
> supplied usec value as it wasn't clear what the intended behavior was.
> systemd upstream version tested was from approximately last Friday
> should something have changed recently.

Yes, sd_event_get_now_monotonic() is the right call to use here. It will
return the monotonic time of the current event loop
iteration. Alternatively you could just use now(CLOCK_MONTONIC), but
using sd_event_get_now_monotonic() helps to suppress a syscall...

Lennart

-- 
Lennart Poettering, Red Hat