[personal profile] mjg59
A reasonably common design for applications that want to run code at a specific time is something like:

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.

Date: 2011-11-19 02:21 am (UTC)
From: (Anonymous)
With the line between a system being awake and a system being asleep getting blurrier and blurrier, it seems a very good idea to fix this behaviour before it is going to bite everyone when things like autosuspend become more common.

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.

Date: 2011-11-20 12:28 am (UTC)
From: (Anonymous)
Some people may expect sleep() to mean "I have 10 minutes of computation to do in another thread, so don't wake me up until that computation is over."

(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.)

Profile

Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Aurora. Ex-biologist. [personal profile] mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer. Also on Mastodon.

Page Summary

Expand Cut Tags

No cut tags