Hi, Tomas Volf <[email protected]> skribis:
>>> I have no idea how Shepherd works internally (and much less how Fibers >>> work), so maybe this comment is completely off, but this seems >>> suspicious. Should this lambda not get the wake up time as an argument, >>> instead of calling get-internal-real-time to get the "now"? >> >> Yes, it would probably be nicer, but it wouldn’t make much of a >> difference here (and it’s not related to the bug: the bug shows that we >> sleep longer than asked for). > > I am not sure this is correct. What the bug shows is that the callback > is called later then expected. We do not know how long the sleep was. > Am I missing something? The bug is that it slept longer than expected, not that it was late, if you see what I mean. >> Maybe this: >> >> (define max-delay >> ;; Time after which we consider that we missed the deadline. Tolerate a >> ;; slight drift, which can happen occasionally. >> (max (min (/ seconds 10.) 120) 2)) > > That should work, yeah. At least as a temporary measure. :) Heh, agreed. Pushed as 7a7b4e16f9697c4822b7693e63cc4ba0ace134a2. > Few additional data-points: The timers I have scheduled for almost 24h > in the future fired exactly on time. As for the kerberos-log-in-refresh > timer, twice it fired within the 2 seconds (12:00:01), once outside > (12:00:02). OK. > I was thinking about this some more, and the right solution here > probably is to use netlink to listen for ACPI events, the same way acpid > does. That should provide reliable information about the suspend and > resume events. Sounds like a good idea (though it’s a bit annoying to depend on guile-netlink and low-level details). Another thing I had in mind was to use an elogind hook so that shepherd would know when we’re suspending; this is necessary for other things such as locking LUKS devices on suspend. But that’s a change for 1.1.x. Thanks, Ludo’.
