Am Sa., 18. März 2023 um 15:54 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Sat, Mar 18, 2023 at 9:20 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> 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.

I didn't and don't want to make such statements about SRFIs I didn't author.

> There is no reason not to duplicate the rationale from SRFI 18; this SRFI should be as self-contained as possible.

I am not going to make the SRFI text any longer for no good (or better
or more important) reason.

That one needs some synchronization primitives on top of the thread
creation API doesn't need to be explained in a rationale IMO.

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

They serve as examples.

>>
>> > 7. A blank line is missing before (current-continuation-marks).
>>
>> Where exactly?
>
>
> At the point just before the definition of `current-continuation-marks`.

Maybe someone else can check; in my browser, I see a blank line.

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

One reason is that this is how it is specified in SRFI 157 and in
Racket.  Moreover, arbitrary keys (e.g. records) can make sense for
some applications.

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

Chapter 10 uses the phrase "exits normally" with respect to
communication with the OS.  It is outside the standard of what this
means (because it is OS-dependent).  I just reuse this phrase.

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

I don't want to add another sublibrary for no good reason (especially
not at this point of the finalization process).

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

The same interrupt can happen within the code of `thread-sleep!`.

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

Quite the contrary; it must immediately timeout when it receives a
time in the past because the deadline is already over.

I am adding a note about this.

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

Thanks, fixed.