microseconds update

[Ryan Lortie <desrt desrt ca>]

hi everyone,

I wrote an email yesterday detailing my goals to reduce GLib to having a
single type for time.  The work just landed on master.

Of course, there were complications.

Status report:

 - GTimeSpec is gone

 - g_get_monotonic_time() returns int64 time

 - new function g_get_real_time() returns wall clock int64 time

 - it's not really possible to deprecate GTimeVal at the moment due to
   its appearance in a large number of APIs and (most annoyingly) on the
   vtable of the thread implementation.

   It's on the glib4 kill list and I added a docs note about that.

 - GTimer is also not deprecated because it has a lot of users and it's
   not immediately clear that we should disrupt them.  GTimer is
   switched to monotonic time, though, and is using int64 internally.

   I had one uneasy feeling while looking at removing GTimer.
   g_timer_elapsed() rather conveniently returns a double -- which is
   great for whacking directly into a printf statement.  Many people use
   it this way.  Of course, it's quite easy to do the math yourself, but
   not quite as nice.


So far I'm using int64 everywhere, but I wonder if we should introduce
some extra meaningless typedefs to improve the self-documentation of
function signatures and user code.  We already have GTimeSpan to
represent the distance between two times, but it's clear that we should
not use that for absolute representation of either monotonic or
wallclock time.  Perhaps we should also have two new types to represent
absolute values of wall-clock time and monotonic time.

I'm not crazy about the caps used on GTimeSpan (being that it's an
integer type).

I guess my preferred names for the new types would be "gmonotime" and
"grealtime".  We could also go the route of having a single new type,
gtime.

Or nothing at all.


Cheers