Re: microseconds ought to be enough for anybody

[Yasushi SHOJI <yashi atmark-techno com>]

Hi,

# I'm not an expart of data/time, timer precision or anything.  but,
# working with some embedded systems. so I might be biased by that.

At Mon, 01 Nov 2010 12:06:48 -0400,
Ryan Lortie wrote:
> 
>   - microseconds ought to be enough for anybody
> 
>      A nanosecond is on the scale of individual clock cycles and
>      processors are getting slower, not faster.  I have an extremely
>      hard time imagining this sort of precision being meaningful (much
>      less, actually useful) in our platform.  Heck; our mainloop is
>      still based on milliseconds.

I like the principle of making easy things easy.

>   - use of int64-as-microseconds is already extremely common
> 
>      This is another reason to avoid doubles.

mind to give us some examples, if you have time?

> The conclusion of all of this is one point: barring substantial
> complaints, the be-all and end-all of time in glib is going to be
> microseconds stored in a gint64.
> 
> GDateTime already calls this a "GTimeSpan".  That's OK.
> 
> 
> I will do the following:
> 
>   - rip out the newly introduced GTimeSpec and all APIs using it
> 
>   - deprecate GTimeVal and all APIs using it
> 
>   - replace both with APIs using int64 of microseconds
> 
>   - deprecate GTimer
> 
>     with int64-based time, it's trivially easy to do it yourself

what does glib give to people who's trying to solve hard things?

Linux kernel, in paticular, after the looong discussion and hard
works, get the high resolution timer and dynamic tick support to solve
this hard things.  would it be an API bloat to leave nano second
precision interface to use those new features? or add them after you
simplified as above?

it is not like we want to run the main loop in every 1 nsec, but some
time it is handy to have sub micro seconds precision when you are
working on audio or controlling hardware.  I know glib is developed
for Gtk+ based apps, but these days, many, if not a lot, application
is using glib as base frame work.  and, IMO, good frame work should
have some way to solve those hard things.

thanks,
-- 
            yashi