jay@splut.UUCP (Jay Maynard) (04/03/88)
I spent about 4 hours last night trying to figure out where I was going wrong with my use of the times(2) function. I wrote the test program below, and it would work fine; then I used it in a much larger system (the KA9Q TCP/IP package - the supplied timer routine only ticks once a second), and it would break. I didn't discover the problem until I compiled the test program with -Ml - then it, too, was broken. times(2) is documented to return, besides the cpu times in the structure that is passed as its parameter, a monotonically increasing number that is the elapsed real time in 60ths of a second since the machine was booted. In small model, it does this just fine; in large model, it always returns -1. (argh!!) Guess I'll have to go hack something up... Here's the test program. It will work fine (print the times(2) return value each time you hit enter) in small model, but will always print -1 if compiled with -Ml. -----------8<----------cut here-----------8<------------------ #include <stdio.h> #include <sys/types.h> #include <sys/times.h> main() { long thistime, times(); int c; struct tms *timesbuf; for (; c != EOF; (c = getchar())) { thistime = times(timesbuf); printf(" %ld\n", thistime); } } -- 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. The opinions herein are shared by none of my cats, much less anyone else.
james@bigtex.uucp (James Van Artsdalen) (04/04/88)
IN article <463@splut.UUCP>, jay@splut.UUCP (Jay Maynard) wrote: > times(2) is documented to return, besides the cpu times in the structure > that is passed as its parameter, a monotonically increasing number that > is the elapsed real time in 60ths of a second since the machine was > booted. In small model, it does this just fine; in large model, it > always returns -1. (argh!!) 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... In the program included, > struct tms *timesbuf; should be "struct tms timesbuf", and > thistime = times(timesbuf); should be "thistime = times(×buf)", according to my documentation. -- James R. Van Artsdalen jva@astro.as.utexas.edu "Live Free or Die" Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746
jay@splut.UUCP (Jay Maynard) (04/13/88)
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!