From: John Cowan <xxxxxx@ccil.org>
Date: Monday, August 12, 2019 9:06 AM
Perhaps a vote for adding [ nanosleep ] ??
I have an issue with it, namely that it suspends the current Posix thread, but Scheme threads don't necessarily match Posix threads 1:1, in which case it would have to be multiplexed using the Scheme implementation's event loop. I'm not sure that's worthwhile given that you only get millisecond precision. Sleep can never affect correctness in properly written threaded programs.
Alternatively we'd have to document that sleep may suspend threads other than the current one.
Those are good arguments, but I do really want a "put this thread to sleep for X", somewhere, someplace, for which milliseconds is fine, as opposed to for example spinning and repeatedly checking the current time.
This very limited timespec SRFI sounds ... very limited.
The main reason for the timespec SRFI to get rid of the shared-structure issue, since it will be shared between at least two SRFIs, probably more. For that to work, constructor and accessors are necessary and sufficient. Adding comparators just makes sense in the general R7RS-large scheme of things.
I don't see how math on them is beyond the scope of R7RS-large, but I've not been involved in anything Scheme from not long after the R6RS vote until this year.
It occurred to me that a timespec-as-interval is just an absolute timespec with an unusual epoch. So I'll add a procedure `timespec-new-epoch` which takes two timespecs which share an epoch and returns the first timespec with its epoch changed to the second timespec. This is just timespec subtraction under a different name.
I don't see that satisfying my strong desire for intervals, and subtraction under a different name is obscurity. And as previously mentioned, I also want addition and multiplication, and division would be nice, e.g. "how many minutes in this interval?" I'm assuming all that, actually the entire SRFI, can be supplied as portable Scheme in the SRFI repo, it's just pairs and fixnums inside them.
That's for async IO. I don't think we should expose async IO at the user level (though as I have been saying it's pretty much necessary in the implemnentation event loop).
Resource temporarily unavailable. This is a temporary condition and later calls to the same routine may complete normally.
I'll confirm what you say, or at least its relevance to this SRFI as I check for EINTR in all the calls, now that we're close to finishing the scope of SRFI-170.
- Harold