[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposed getitimer and setitimer functions

From: Marius Vollmer
Subject: Re: proposed getitimer and setitimer functions
Date: 07 Jul 2001 12:47:33 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.0.102

Rob Browning <address@hidden> 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.
> 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).

Yes, we could allow both.  Adding SRFI-19 support to setitimer can be
done later as a compatible extension, so I wouldn't really worry about
it now other than putting a comment in the code that this is

> > 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).

There is a section in the manual about error reporting of POSIX
functions, "POSIX Interface Conventions".

> > 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,

(multiple values are in R5RS)

> 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.

Yes, and I hope to adopt more Common Lispish semantics in the future
in that you can silently ignore additional return values.  The current
implementation of values and call-with-values is not really the Right
Thing, I'd say.

> > 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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]