[omniORB] changing system clock

[Geoffrey Hanson]

Another way to solve this is to, instead of
having get_time() return the wall clock, you
can have it return the time since the system
booted. POSIX has some routines to do this. I'm
not sure about non-POSIX systems. This makes you
immune from system clock changes.

The only cases where using this method would be
invalid would be where you actually need the
wall clock time. For example, if you're printing
out a log with the time. However, all callers of
get_time() that I could see were simply using the
time for timing purposes.

.....Geoff

---
Geoff Hanson         Fabric7 Systems
hanson at fabric7.com   1300 Crittenden Lane,       
650-210-0116              Suite 302
                     Mountain View, CA 94043


> -----Original Message-----
> From: Duncan Grisby [mailto:duncan at grisby.org]
> Sent: Thursday, May 18, 2006 4:09 AM
> To: Geoffrey Hanson
> Cc: omniorb-list at omniorb-support.com
> Subject: Re: [omniORB] changing system clock 
> 
> 
> On Wednesday 17 May, "Geoffrey Hanson" wrote:
> 
> > Are you saying that all the other callers of
> > get_time() do not have a problem when the system
> > clock is changed?
> 
> No -- they will have a problem.
> 
> > For example, if I have a client timer set to, say
> > 30 seconds, and I change the time backwards, would
> > the client timer still time out after 30 seconds?
> 
> No, it will time out when the absolute time reaches the 
> deadline set for
> the call. I don't think this is an avoidable problem -- calls involve
> doing multiple separate steps, all of which might time out. After each
> step, you have to know how long the step took, so you can reduce the
> timeout for the next step accordingly. The only general way to do that
> is to look at the time, so if time jumps forwards or backwards, you're
> in trouble.
> 
> Cheers,
> 
> Duncan.
> 
> -- 
>  -- Duncan Grisby         --
>   -- duncan at grisby.org     --
>    -- http://www.grisby.org --
>