Re: setting date stops networking?

[nisse@lysator.liu.se (Niels Möller)]

neal@cs.uml.edu (Neal H. Walfield) writes:

> If you are losing network access then I doubt time is the problem; it
> is likely pfinet.

It could well be that the timeout code in pfinet uses system time, and
is confused by abrupt system time changes.

It is actually quite tricky to write timeout code that is robust to
abrupt system time changes. I.e. when one wants something to happen in
roughly 5 real seconds, no matter if the system time is set back or
forward a day or two.

The *only* POSIX way to get system-time-change-independent wall clock
time, which I've been able to find, is the return value of the times()
function (see section 8.15, Stevens' Advanced programming in the UNIX
environment). The single unix specification
(http://www.opennc.org/onlinepubs/7908799/xsh/times.html) describes it
as follows:

: Upon successful completion, times() returns the elapsed real time,
: in clock ticks, since an arbitrary point in the past (for example,
: system start-up time). This point does not change from one
: invocation of times() within the process to another. The return
: value may overflow the possible range of type clock_t. If times()
: fails, (clock_t)-1 is returned and errno is set to indicate the
: error.

But the times() function in glibc returns _cpu time_, not _wall clock
time_ (at least according to the glibc documentation *Note Processor
Time: (libc)Processor Time):

:  - Function: clock_t times (struct tms *BUFFER)
:      The `times' function stores the processor time information for the
:      calling process in BUFFER.
: 
:      The return value is the calling process' CPU time (the same value
:      you get from `clock()'.  `times' returns `(clock_t)(-1)' to
:      indicate failure.

To me, this seems like a glibc bug. I would be greateful for comments
from Roland, or some other person familiar with both glibc and POSIX.

Regards,
/Niels