glib "bug": g_timeout_add() not robust with respect to clock changes

[Alan Robertson <alanr unix sh>]

Hi,

I'm not on the list, so please CC me personally.

I'm the team leader for the linux-HA (high-availability) project, and we use
glib a good bit.  However, there are a few things which make it less useful
to us in this non-GUI, continuously running environment than it could be.

The one I'm writing about now is that g_timeout_add() and
g_timeout_add_full() calls rely on time_ts to tell if the timeouts have been
exceeded.

This doesn't work when the system time is changed, because the two time
values are relative to different time bases, and are no longer comparable.
This means that at infrequent and unpredictable times, programs which use it
will misbehave - possibly fatally.

What we've done to work around this is to develop some replacement
interfaces G_main_timeout_add() and G_main_timeout_add_full() which use
longclock_t's to track timeouts.

guint Gmain_timeout_add(guint interval
,       GSourceFunc     function
,       gpointer        data);

guint Gmain_timeout_add_full(gint priority
,       guint interval
,       GSourceFunc     function
,       gpointer        data
,       GDestroyNotify  notify);

The longclock_t types are 64-bit versions of clock_t values that come from
the times(2) call.  This works wonderfully because POSIX states that
successive times(2) calls in a given process are always relative to the same
epoch.  clock_t's wrap around every 10 months or so, but longclock_t's wrap
about every 2 billion years.  This makes it someone else's problem ;-)

Unfortunately, FreeBSD doesn't follow the POSIX standard in the case of
times(2), and the epoch for a given process isn't constant :-(.  To fix it
appears to require some kernel change in FreeBSD.  But, it's no worse than
the current implementation.

Both the code for the Gmain_timeout... and longclock_t code are available
under the GNU LGPL.

	-- Alan Robertson
	   alanr unix sh