On Thu, Nov 17, 2022 at 10:32 AM Marc Nieper-Wißkirchen < marc.nie...@gmail.com> wrote:
> > This should be no change; I always meant the interrupts must be queued. > Ah, I see. I've read "Schedule an interrupt for thread when ..." so thread-interrupt! is ignored when current-interrupt-level is not zero. But it is "for when". I may be the only one who's sloppy, but a sentence may be added to current-interrupt-level or enable-interrupts! saying that when the current-interrupt-level drops zero, scheduled interrupt thunks run. > (do-X) runs in thread T. So 2. will interrupt it. > > If you don't want this, wrap (do-X) in (with-interrupts-disabled ...). > That doesn't cut it, for 2 can interrupt before (with-interrupts-disabled ...), so inversion of order can still happen. (Similar issue that the original Unix signal handler had.) Of course, it doesn't matter if we don't guarantee the order of signals. If that's the case, I'd like the spec says so. The user can seriarize signal interrupts using external thread-safe queue, so it's not a big issue. But the user needs to be aware that reordering can occur and write the thunk code accordingly.
