Re: proposed getitimer and setitimer functions

[Rob Browning]

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.

OK.  Sounds reasonable.  Actually, another alternative would be to use
srfi-19 time objects, but that's also just a pair of ints (nanosecs
and secs).  My initial impulse was to just wrap the C interface as
thinly as possible, but bignums would certainly be less unweildly.

> The "result-int" should be interpreted and turned into a
> `system-error', I'd say, for consistency with the POSIX functions.

OK.  I'd just copied alarm, but had forgotten that it has different
return value semantics.  I'll change it to behave like the other POSIX
functions.  Is there any documentation for how we want that handled
(I'm looking at gethostbyaddr ATM as an example).

> Do we want to use `values' for returning multiple values?

Dunno.  Do we have any convention about that?  Using multiple values
is non-standard scheme, but code using setitimer isn't going to be
portable anyhow.  Further, multiple values is something that can
perhaps be optimized performance-wise in some situations more heavily
than returning a list.

> The change is very self-contained and so I don't see a problem with
> including it on short notice.

Great.

> Hmm, I'd say that primitives should do type checking as early as
> possible since you don't get a backtrace from primitives calling each
> other in the backtrace.

OK, so to make sure I follow you correctly, that would argue in favor
using the SCM_VALIDATE_FOO macros here, right?

Thanks

-- 
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C  64AE 78FE E5FE F0CB A0AD