Making timeouts work with suspend
Nov. 17th, 2011 08:39 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
A reasonably common design for applications that want to run code at a specific time is something like:
This works absolutely fine, except that sleep() ignores time spent with a suspended system. If you sleep(3600) and then immediately suspend for 45 minutes you'll wake up after 105 minutes, not 60. Which probably isn't what you want. If you want a timer that'll expire at a specific time (or immediately after resume if that time passed during suspend), use the POSIX timer family (timer_create, timer_settime and friends) with CLOCK_REALTIME. It's a signal-driven interface rather than a blocking one, so implementation may be a little more complicated, but it has the advantage of actually working.
time_t wakeup_time = get_next_event_time(); time_t now = time(NULL); sleep(wakeup_time-now);
This works absolutely fine, except that sleep() ignores time spent with a suspended system. If you sleep(3600) and then immediately suspend for 45 minutes you'll wake up after 105 minutes, not 60. Which probably isn't what you want. If you want a timer that'll expire at a specific time (or immediately after resume if that time passed during suspend), use the POSIX timer family (timer_create, timer_settime and friends) with CLOCK_REALTIME. It's a signal-driven interface rather than a blocking one, so implementation may be a little more complicated, but it has the advantage of actually working.
no subject
Date: 2011-11-19 02:21 am (UTC)I am not claiming that the current behaviour is against the spec, but come on, let common sense kick in and fix this madness.
Using something else than sleep() is not an option because select/poll/etc. have the same unexpected behaviour.
no subject
Date: 2011-11-20 12:28 am (UTC)(However wrong sleep() is for the formulation that I have written here, that's just because I can't clean up the formulation to make sleep() sensible.)