pthread_condattr_setclock() and CLOCK_BOOTTIME

[Hannu Mallat <hannu dot mallat at jolla dot com>]

Hi all,

I'm wondering if there would be any ill effects from allowing more
clock IDs in pthread_condattr_setclock()?

I was investigating a problem of glib2 timeouts not triggering when
the platform I'm working on (Jolla, a Linux-based smartphone) is
suspended. This was because glib2 is using CLOCK_MONOTONIC as its time
source (in g_get_time_monotonic()), and CLOCK_MONOTONIC does not
increment during suspend; neither does it jump forward when the device
wakes up. So a timer that would trigger in T seconds at the time of
entering suspend is still the same when the device wakes up, no matter
how long it has been suspended. Timed activity with outside entities,
e.g., DHCP lease renewal, obviously suffers from this.

Using CLOCK_BOOTTIME as the glib2 time source instead solves the
problem of clock not advancing after waking up, and I can schedule a
wakeup at a suitable time by platform-specific means; but glib2 also
makes calls to pthread_condattr_setclock() and currently glibc only
allows the clock id to be CLOCK_MONOTONIC or CLOCK_REALTIME. 

I have made a patch that allows also CLOCK_BOOTTIME to be used (the
size of the bit field used to store the clock id is widened to 3 bits
to fit CLOCK_BOOTTIME id) and on the face of it, it works nicely.

However I'd like to get more feedback whether a change like this could
break something I'm not seeing at the moment. Or are there some other
arguments against the change?

We're using glibc 2.15 at the moment.


Best regards,
Hannu