Re: microseconds update
- From: Stefan Kost <ensonic hora-obscura de>
- To: gtk-devel-list gnome org
- Subject: Re: microseconds update
- Date: Thu, 04 Nov 2010 17:57:37 +0200
On 03.11.2010 04:39, Ryan Lortie wrote:
> 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).
>
We have a few macros in GStreamer
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gstreamer/html/GstClock.html
and those are certainly improving the readability of the code.
Stefan
> 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
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]