On Friday, January 9, 2009 2:32 am Daniel Stone wrote:
> On Fri, Jan 09, 2009 at 09:27:25AM +0100, Michel Dänzer wrote:
> > On Thu, 2009-01-08 at 11:13 -0800, Jesse Barnes wrote:
> > > On Thursday, January 8, 2009 2:13 am Daniel Stone wrote:
> > > > You probably want to get the entire clock_gettime awesomeness, to
> > > > avoid the pathological worst case of rewinding the clock during a
> > > > wait which is destined to time out: rewind the clock 11h, 0.5sec into
> > > > the wait, and you'll be blocked for 11h and 0.5sec.  CLOCK_MONOTONIC
> > > > ftw.
> > >
> > > CLOCK_MONOTONIC isn't supposed to go backwards though; it can't be set
> > > (at least according to spec).  So I must be missing something here...
> >
> > I interpreted Daniel's words such that while the monotonic clock can't
> > go backwards, it may 'stand still' indefinitely. Right, Daniel?
> >
> > If so, maybe it would be better to simply use gettimeofday() and time
> > out if the absolute delta is >= 1^6 us. That'll result in the timeout
> > being slightly early or late if the clock jumps, but that's probably a
> > better failure mode than a hang.
>
> Sorry, I didn't realise you'd also taken the CLOCK_MONOTONIC stuff.
> Clearly more Sudafed required.  MONOTONIC will always go forward (cf.
> jiffies), so you don't have to worry about anything, as long as you're
> not trying to correlate the result of clock_gettime(CLOCK_MONOTONIC, ...)
> and gettimeofday().

Oh right, that would be a recipe for lolz.  I think CLOCK_MONOTONIC is safe 
enough for now...

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center

------------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel

Reply via email to