[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-17 10:02 pm (UTC)
From: (Anonymous)
The reason why I asked is that we have a similar issue in glib with g_timeout_add(). And I've been wondering if the correct approach is to do what you did and then adding a g_call_me_when_this_clock_time_has_been_hit() callback for being woken up at a certain point in time. Or if it's better to do it the other way.

What do most people actually expect when they schedule a timeout or call sleep()? Any guesses?

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