[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
anticipated.
> > 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?
Yes.
- proposed getitimer and setitimer functions, Rob Browning, 2001/07/06
- Re: proposed getitimer and setitimer functions, Thomas Bushnell, BSG, 2001/07/06
- Re: proposed getitimer and setitimer functions, Marius Vollmer, 2001/07/07
- Re: proposed getitimer and setitimer functions, Rob Browning, 2001/07/07
- Re: proposed getitimer and setitimer functions, Marius Vollmer, 2001/07/12
- Re: proposed getitimer and setitimer functions, Rob Browning, 2001/07/13
- Re: proposed getitimer and setitimer functions, Marius Vollmer, 2001/07/22
- Re: proposed getitimer and setitimer functions, Thomas Bushnell, BSG, 2001/07/07
- Re: proposed getitimer and setitimer functions, Marius Vollmer, 2001/07/07