[EMAIL PROTECTED] (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
