clock_t times(struct tms *buf);
struct tms {
clock_t tms_utime; /* user time */
clock_t tms_stime; /* system time */
clock_t tms_cutime; /* user time of children */
clock_t tms_cstime; /* system time of children */
};
The tms_utime field contains the CPU time spent executing instructions of the calling process. The tms_stime field contains the CPU time spent in the system while executing tasks on behalf of the calling process. The tms_cutime field contains the sum of the tms_utime and tms_cutime values for all waited-for terminated children. The tms_cstime field contains the sum of the tms_stime and tms_cstime values for all waited-for terminated children.
Times for terminated children (and their descendants) are added in at the moment wait(2) or waitpid(2) returns their process ID. In particular, times of grandchildren that the children did not wait for are never seen.
All times reported are in clock ticks.
sysconf(_SC_CLK_TCK);
In POSIX.1-1996 the symbol CLK_TCK (defined in <time.h>) is mentioned as obsolescent. It is obsolete now.
In Linux kernel versions before 2.6.9, if the disposition of SIGCHLD is set to SIG_IGN then the times of terminated children are automatically included in the tms_cstime and tms_cutime fields, although POSIX.1-2001 says that this should only happen if the calling process wait(2)s on its children. This non-conformance is rectified in Linux 2.6.9 and later.
On Linux, the buf argument can be specified as NULL, with the result that times() just returns a function result. However, POSIX does not specify this behavior, and most other Unix implementations require a non-NULL value for buf.
Note that clock(3) also returns a value of type clock_t, but this value is measured in units of CLOCKS_PER_SEC, not the clock ticks used by times().
On Linux, the "arbitrary point in the past" from which the return value of times() is measured has varied across kernel versions. On Linux 2.4 and earlier this point is the moment the system was booted. Since Linux 2.6, this point is (2^32/HZ) - 300 (i.e., about 429 million) seconds before system boot time. This variability across kernel versions (and across Unix implementations), combined with the fact that the returned value may overflow the range of clock_t, means that a portable application would be wise to avoid using this value. To measure changes in elapsed time, use gettimeofday(2) instead.