Re: threading / timers / etc

[Ryan Lortie <desrt desrt ca>]

hi Pavel,

On Mon, 2010-10-25 at 11:24 +0200, Pavel Holejsovsky wrote:
> Just out of curiosity; would you mind trying to specify reasons why you 
> don't like it?

My general uneasiness with this idea developed along these lines:

 - If we have some API for getting this int64 for the current time then
        it makes sense that we probably also want to have an API for
        converting between GTimeSpec and this int64.
        
 - If we have that API then we need to initialise the process-specific
   offset the first time the API is used to convert a GTimeSpec to a
   int64.

 - It's not clear what would happen if we tried to do a int64 to
   GTimeSpec conversion first.  Crash?  Critical?

 - If someone passes a bogus GTimeSpec to the conversion call the first
   time then your process is more or less hosed for its entire life.


I settled on the idea that we might want to have more locally-scoped
epochs (like the time at which a GPeriodic was created, for example).


                Because the only complication I can see with this 
> solution is that the clock is not monotonic across process borders 
> (although it is a bit hard for me right now to invent situation where 
> this would matter).

We're already planning to inject timestamps received from the X server
for vblank (generated in the kernel IRQ handlers, I think?) directly
into GPeriodic.  I can easily imagine other situations where this might
be useful.


Cheers