Hi Akim, > Here is my proposal to rely on gnulib for time issues. > > commit 382f32bb5696168a80fbae5c5dc9dd6c1342e68b > Author: Akim Demaille <akim.demai...@gmail.com> > Date: Tue Oct 2 06:19:19 2018 +0200 > > timevar: rely on gnulib modules for time portability. > > * modules/timevar (Depends-on): Add sys_time, sys_times, and times. > * m4/timevar.m4: Don't check for clock_t and struct tms, > guaranteed by gnulib. > * lib/timevar.h: Use extern "C" protection. > Include <stdio.h> for FILE. > * lib/timevar.c: Include sys/time.h, sys/times.h unconditionally, > they are guaranteed by gnulib. > Remove uses of clock as (now useless) fallback.
Looks all right to me. You can push it. > > - Is the 'times' approach preferrable to the 'getrusage' approach in all > > cases? I’m thinking of multithreading and of processes that fork() > > children. > > On this machine, man times gives: > > > SYNOPSIS > > #include <sys/times.h> > > > > clock_t > > times(struct tms *tp); > > > > DESCRIPTION > > This interface is obsoleted by getrusage(2) and gettimeofday(2). This sentence is a personal opinion by whoever wrote the man page. http://pubs.opengroup.org/onlinepubs/9699919799/functions/times.html does not say that this interface is obsolete or deprecated. > So I guess in all cases I should prefer getrusage to times. > Yet getrusage does not give me the wall clock time, so I > suppose I should use getrusage + time (not times). time() gives the wall-clock time with 1-second resolution only. You should better use gettimeofday() instead of time(). > https://stackoverflow.com/a/12480485/1353549 I would conclude that either times() or getrusage()+gettimeofday() provides the necessary functionality. Which one to choose? I think it's useful to compare the results on various platforms (regarding precision and behaviour regarding children processes), to see which one is better. Bruno
