> On Nov 11, 2022, at 12:19 PM, Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
> I have documented thread-interrupt! in 5.14.6.
>
> Thread-exit! is now renamed to thread-stop!.
>
> I hope that only editorial changes remain before we finalize this.
>

I have problems understanding the spec for thread-interrupt!:

(thread-interrupt! thread thunk)      procedure

Schedules an interrupt for thread for when the current-interrupt-level of thread is zero. The current continuation of thread is then replaced by a continuation that records the values it receives, invokes thunk with no arguments, discards its values, and then yields the recorded values to the original continuation.

Note: An interrupt can occur while a thread is blocked waiting on a condition variable.

It mentions “replacing” the current continuation of the target thread by a new one.  I don’t understand that model which seems to assume that the computation moves from continuation to continuation (i.e. that calling a continuation marks the beginning of a computational step).  I think it also assumes that every point where a continuation is called is a “safe point” where the Scheme VM is in a consistent state.  But when a program is written in continuation passing style the implicit continuations are never called because the computation is strictly a sequence of tail calls with no returns.  Also the simple infinite loop (let loop () (loop)) never calls a continuation… so does that mean it can’t be interrupted?

I think a better way to explain it is that every expression <expr> in the program is conceptually treated as (begin (poll-interrupts!) <expr>) and then give a definition of (poll-interrupts!) that checks the current-interrupt-level and calls any pending interrupt thunks.  Also, the spec must explain that (for performance reasons) the implementation may postpone the polling, but only for a bounded time.  An interrupt check must also be performed when the interrupt-level is set to 0, either due to a call (enable-interrupts!) or (current-interrupt-level 0) or on the way out of a binding done with (parameterize ((current-interrupt-level …)) …) or on the way in of a binding done with (parameterize ((current-interrupt-level 0)) …).

The second comment is about the note “An interrupt can occur while a thread is blocked waiting on a condition variable”.  A thread can be interrupted in the “runnable” and “blocked” states, not just blocked on a condition variable (for example it could be blocked on a mutex, or sleeping).  The only situations where it can’t be interrupted is when the interrupt level is not 0, or when the state of the thread is “new” (i.e. created but not yet made runnable) and “terminated”.

Finally, the current-interrupt-level mechanism may be too coarse.  Perhaps an interrupt level per interrupt source might be needed for some applications.  I think the current design is OK for now if current-interrupt-level is seen as a “global” interrupt masking machanism.  A future SRFI can add a mechanism that is more fine-grained.  I think this could be implemented on top of the interrupt mechanism of this SRFI.

I’m slowed down by other things right now so I can’t yet comment on the rest of SRFI 226.

Marc