On Sat, Mar 18, 2023 at 9:20 AM Marc Nieper-Wißkirchen < [email protected]> wrote:
> 2. There are no rationales provided for mutexes, condition variables, or > interrupts. > > Mutexes and condition variables are already in SRFI 18. > That's a point I should have made: why is SRFI 18 not in the list of superseded SRFIs? It's certainly possible to implement the thread features without making use of SRFI 18: indeed, the sample implementation does so. There is no reason not to duplicate the rationale from SRFI 18; this SRFI should be as self-contained as possible. > 4. Given that `shift` and `reset` are provided as a library, `control` > and `prompt` should also be provided. > > This is left to a future SRFI if people feel the need to have a > predefined control/prompt pair. Shift/reset seems to be much more > common. > In that case, references to control/prompt should be removed altogether. > > 7. A blank line is missing before (current-continuation-marks). > > Where exactly? > At the point just before the definition of `current-continuation-marks`. > > 8. It's unclear what the use of `continuation-mark-key?` is. Under what > circumstances would key objects be treated specially? > > It can be used if you want to guard against not using the most > efficient way to use continuation marks in a given Scheme system. > In that case, why not simply require the use of key objects as generated here? > > 10. A blank line is missing before (curent-parameterization). > > Where exactly? > See #7. > > 12. In the same place, "exits normally" should just be "exits", as the > semantics of normal and abnormal exits from a top-level program is > unspecified. In particular, a top-level program that passes #f to its > continuation may be equivalent to calling (exit #f). > > I use the language and semantics from Chapter 10 of the R6RS Standard > Libraries here. > Chapter 10 makes no reference to exiting by invoking the initial continuation. If you mean to inherit the semantics of `exit` (which are slightly different in R6RS and R7RS), you should say so. As things stand, a program that passes #f to its initial continuation exits normally rather than abnormally. (Section 8.2 of the main R6RS report also does not explain what happens when the initial continuation is invoked.) > 15. It is unclear what the purposes of `exception-handler-stack` and > `exception-handler` might be. > > Current-exception-handler is already in SRFI 18; the > exception-handler-stack procedure can be used for inspection or for > low-level library code dealing with the exception system. SRFI 229 > can be used to add meta information to the handlers. > In that case, `exception-handler-stack` should be exported from an (or the) inspection library. > > 16. A relative timeout is not equivalent to the value of (current-time) > incremented by the relative value, because relative timeouts are relative > to the time when the procedure `thread-sleep`, `thread-join!`, > `mutex-lock!` or `mutex-unlock!` is called. This by definition will not be > the same as the time when `current-time` is called. I believe the Right > Thing is to split the four procedures in two, one accepting an absolute and > the other a relative timeout, e.g. `thread-sleep!` and `thread-sleep-for!`, > or alternatively `thread-sleep-until!` and `thread-sleep!` (and likewise > for the other three). > > You can calculate the timeout at the point where you call > `thread-sleep!`, etc. > No, you can't. Necessarily the call to current-time happens before the call to thread-sleep, and there is no assurance that there is not an arbitrary lapse of time between the one and the other, as by a low-level (non-Scheme) interrupt. By accepting relative times directly, the implementation can assure that there is no such delay. This is fundamental to the reliability of timeouts: a thread-join! whose timeout is now in the past will never time out, which is unlikely to be the intention. Thank you for the extensive perusal of the last draft. > One more point that I noted but forgot to put in my email: the definition of %case-lambda-box-ref refers to %lambda-box-ref.
