Re: threading / timers / etc

[Ryan Lortie <desrt desrt ca>]

On Fri, 2010-10-22 at 15:02 -0400, Havoc Pennington wrote:
> Hi,
> 
> On Fri, Oct 22, 2010 at 11:06 AM, Ryan Lortie <desrt desrt ca> wrote:
> >  - We will add GTimeSpec which is GTimeVal using nanoseconds instead of
> >    microseconds (same story with struct timeval vs. struct timespec).
> >    The librt interfaces provide this level of accuracy so it would be a
> >    shame to needlessly discard it.
> 
> I know this is a completely minor side issue to the point of your
> email (which sounds good overall) but I often find myself writing a
> convenience wrapper around g_get_current_time() that returns a single
> integer. If you do get_time(TimeSpec*) it might be nice to also do a
> "uint64 get_time_milliseconds()" wrapper.

Unfortunately the system monotonic clock is specified as "since some
unspecified starting point" (ie: you may not assume that it is zero when
the system started).  For this reason, and because the time_t from the
kernel could already be quite large, we can not safely stick monotonic
time into a single int64 with any precision greater than whole seconds.
This is not true with wallclock time, where we can safely assume that
our software will not be running in the year 20000 (Y20K bug?).

Of course, it's "unlikely" that an OS would choose to do this...  I
don't feel willing, though, to hardcode sanity assumptions of every OS
kernel in the world into an API design.

I briefly considered having a per-process epoch whereby the first time
you request the monotonic time, that becomes "time zero".  After rolling
it over in my head a few times, I like it less and less.

I do plan to mitigate the problem substantially by providing some
convenience API for GTimeSpec -- add, subtract, return difference as
int64 of nanoseconds, create from milli/micro/nanoseconds, etc.  These
should help the situation quite substantially.

For something like GPeriodic, of course, we can continue to safely emit
the timestamp as an int64 number of microseconds (or nanoseconds, even),
relative to the time at which the GPeriodic was created (or first
started running).

Cheers