On Thu, May 9, 2019 at 7:36 AM Lassi Kortela <xxxxxx@lassi.io> wrote:

Should time stuff be in scope for this SRFI? I would leave it out,
except for file timestamps. The rationale is as follows.

 >(process-times)
 >Returns four values:
 >user CPU time in clock-ticks
 >system CPU time in clock-ticks
 >user CPU time of all descendant processes
 >system CPU time of all descendant processes
 >Note that CPU time clock resolution is not the same as the real-time
 >clock resolution provided by time+ticks.

This is getrusage(), which is really about process resource usage in general, but it happens that the only portable bits are the system and user times.  It feels like a hangover from the days when people were billed for computer usage by fractions of CPU seconds.  I'm going to remove it.
 
What is CPU time -- If a process runs code on several cores, are all the
cores counted?

All cores or other execution units are summed.
 
 > (cpu-ticks/sec)
 > Returns the resolution of the CPU timer in clock ticks per second.
 > This can be used to convert the times reported by process-times to
 > seconds.

What about CPUs that can adjust their clock frequency while running?

This has nothing to do with the CPU's native cycle time.  It's just the precision of this clock (not its accuracy).  Similarly, clock_getres(CLOCK_REALTIME) delivers the precision of the Posix-time clock, but implies nothing about accuracy.
 
What about counter wraparound?

It's not a counter, it's elapsed CPU time.  If it wraps around, it's broken.   (Either that, or your process has been running for at least 68 years without stopping.)

 > (time+ticks) ---> [secs ticks]
 > The current time, with sub-second resolution. The time is returned as
 > elapsed seconds since the Unix epoch excluding leap seconds, plus a
 > number of sub-second "ticks."

I would recommend being more explicit with the time APIs. Dealing with
time is like quicksand (even more so than OS APIs in general). It's best
to specify precisely what kind of timestamp we want and assure ourselves
that we can reliably get one.

I was, indeed, careful to define it.  It is Posix time, which is sometimes inappropriately called UTC time (but actual UTC time includes leap seconds and has either 60 or 61 seconds per minute).  Because this is the clock used for file times, I think we need to keep at least the seconds portion of it, but I see no reason not to have the nanoseconds (or millisexonds, whatever) as well.


John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
When I wrote it I was more than a little febrile with foodpoisoning
from an antique carrot that I foolishly ate out of an illjudged faith
in the benignancy of vegetables.  --And Rosta