Re: proposed getitimer and setitimer functions

[Marius Vollmer]

address@hidden (Thomas Bushnell, BSG) writes:

> Marius Vollmer <address@hidden> writes:
> 
> > What about collapsing the "secs" and "microsecs" value into one, with
> > a unit of microseconds.  With bignums, we don't need to use long-hand
> > for multi-word numbers.
> 
> A "time" is no more a number than is a "character".  [...]

Yeah, right, I agree completely.  All I know about time is that the
calendar is a very complex thing, with all those time zones, leap
seconds, etc.  There is SRFI-19 (srfi/srfi-19.scm), which is an
attempt at a useful time representation.

Fortunately, setitimer is not about the calendar, it only deals with
durations of time that don't need to unambiguously represent an
absolute point in time, world wide.  So we are only faced with
precision issues.  Are microseconds safe for the future?  For a 1GHz
processor, one microsecond are 1000 clock cycles so I can imagine that
we want to go below one microsecond for profiling in the near future
(not with the interpreter...)

Should we increase the resolution of the Scheme version of setitimer,
or reflect the C version of setitimer mostly unchanged?  The best
thing would be to tack an explicit unit onto the duration.

SRFI-19 provides an abstract type for time durations, which we could
use.  That is, our setitimer could accept both integers as durations,
as well as SRFI-19 `time' objects that represent a duration.

I'm not sure yet how to do this in the cleanest possible way, given
that SRFI-19 is optional.