[omniORB] Setting system time
Cary O'Brien
cobrien@Radix.Net
Wed, 4 Apr 2001 08:45:09 -0400 (EDT)
> >>>>> jon kristensen writes:
>
> > I recently discovered that omniORB 2.8.0 gets into trouble if the system time
> > changes. I found that the scavenger thread seems to use a timed wait, where it
> > just adds a period to an accumulated time value, and waits for the system time
> > to reach that value. If I adjust the system time forward, the scavenger will run
> > in an endless loop until the accumulated time value catches up. Opposite, if I
> > set the time backwards, the scavenger thread will wait (not run) until the
> > system time reaches the value it had before it was set. See
> > orbCore/scavenger.cc, omniORB_Scavenger::run_undetached().
>
> > Am I correct?
>
> I think that is the expected behaviour. The pthread conditional variable
> timed_wait takes a time argument which is the absolute time, as opposite to
> a relative period from now, this is why you are seeing the behaviour.
>
> > Are there any other places in the omniORB code that behaves like this?
>
> No, the scavenger is the only thread that do the periodic housekeeping.
>
> > The reason for my concern is that I synchronize the clocks of all my
> > computers to GPS time (UTC). Invariantly this my cause a large time jump,
> > especially if one of the machines for some reason was not set correctly.
>
> I don't know what you can do about the system time going backward. As for
> the system time going forward, you can modify the scavenger code to use
> omni_thread::get_time to get the time now and then add to it the scan period.
>
I think NTP will adjust the clock by speeding it up/slowing it down
rather than making abrupt changes. Does this help?
ntp: http://www.eecis.udel.edu/~ntp
-- cary
> Sai-Lai
>
>
>
>
> --
> Sai-Lai Lo S.Lo@uk.research.att.com
> AT&T Laboratories Cambridge WWW: http://www.uk.research.att.com
> 24a Trumpington Street Tel: +44 1223 343000
> Cambridge CB2 1QA Fax: +44 1223 313542
> ENGLAND
>
>