Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ncar!boulder!sunybcs!bingvaxu!leah!itsgw!nysernic!rutgers!bellcore!tness7!tness1!splut!jay
From: jay@splut.UUCP (Jay Maynard)
Newsgroups: comp.unix.microport
Subject: Re: YAMB: times(2) is broken in large model
Message-ID: <481@splut.UUCP>
Date: 13 Apr 88 01:17:33 GMT
References: <463@splut.UUCP> <1447@bigtex.uucp>
Reply-To: jay@splut.UUCP (Jay Maynard)
Organization: Confederate Microsystems, League City, TX
Lines: 26
Keywords: this one's a real pain, too...

In article <1447@bigtex.uucp> james@bigtex.UUCP (James Van Artsdalen) writes:
>My documentation does not guarantee that the values returned by times() are
>monotonically increasing.  It would be a useful assumption, and the include
>file /usr/include/sys/proc.h would indicate it is true, but the effect
>on times(2) of stime(2) is not defined.  It would be academic except that
>BSD unix *does* go to the trouble of guaranteeing a monotonically increasing
>clock, and the fact that many uPort 286 users have trouble with cron due to
>the need to constantly adjust the clock...

From the manual:
"Upon successful completion, _times_ returns the elapsed time, in 60ths
of a second, since an arbitrary point in the past (e.g., system start-up
time). This point does not change from one invocation of _times_ to
another."

Am I misinterpreting the second sentence? It looks to me like that
doesn't allow stime(2) to mess up the arbitrary point in the past.

This one is of moderate importance to me, since I don't want all my IP
timers to expire every hour when I do a 'date `/etc/setup -d`'...

[correct analysis of my programming screwup deleted]
-- 
Jay Maynard, EMT-P, K5ZC...>splut!< | GEnie: JAYMAYNARD  CI$: 71036,1603
uucp: {uunet!nuchat,hoptoad!academ!uhnix1,{ihnp4,bellcore}!tness1}!splut!jay
Never ascribe to malice that which can adequately be explained by stupidity.
Pledge #29: Vote for Kent Paul Dolan and the Birthright Party in '88!