gwillen <notificati...@github.com> writes: > In the ccan timer module, there's an assertion that can crash if time moves > backwards. I know there are different perspectives on this, but it seems like > lightningd can probably recover from slight non-monotonicity of time, so it's > worth thinking about whether crashing is the best outcome in this case.
Ouch, thanks! So you know what happened? NTP jump or manual setting? > lightningd: ccan/ccan/timer/timer.c:307: timers_expire: Assertion `now >= > timers->base' failed. > lightningd(24325): FATAL SIGNAL 6 RECEIVED > Fatal signal 6. Log dumped in crash.log > Aborted Yuck. Saying that time shouldn't go backwards is fairly fundamental, and a useful sanity check. Lots of things assume time makes progress. And a library can't report soft errors. OTOH, real life always wins over my personal preferences :) One option is to switch to timemono, which really can't go backwards. But timemono is completely detached from any wallclock time, so it's only useful for relative timers. Which implies an API change to always use relative time (this actually matches with all non-test usage I can find). I'll look harder. Thanks! Rusty. _______________________________________________ ccan mailing list ccan@lists.ozlabs.org https://lists.ozlabs.org/listinfo/ccan
