On 18/08/2025 17:24, Eliot Moss wrote:
On 8/18/2025 11:51 AM, Rob Arthan wrote:
I realised that I was completely misunderstanding the use of the term “synchronous” in the description of the type InterruptState. I now believe that synchronous interrupts require co-operation from the thread being interrupted while asynchronous interrupts are pre-emptive (not the other way round). Have I got it right now?
The documentation says that asynchronous interrupts occur "at a suitable point soon after they are triggered”. Is iit possible to state what the suitable points are.
I can't speak for polyml specifically, but as a virtual machine designer / implementer I can say that designs are simpler and more robust if one uses vm-inserted checks for interrupts, done at places where the low level vm state is relative "clean". The goal is to limit the number of kinds of places while still keeping interrupt latency bounded and relatively low. A typical design would check at calls and/or returns and at loops (backward branches). The latter may manifest as tail calls in a number languages.
Exactly what the places are is a VM design choice, not a language design choice, so it is appropriate that it be a bit vague while perhaps stating the semantic guarantee (bounded time) and performance hope (generally short).
Yes. It actually uses a single check for stack overflow and for an interrupt. An interrupt causes the stack limit to be set to the start of the stack so the next check will cause the thread to call into the run-time system. Stack check code is inserted at the start of most functions and also in loops. However, there is no interlock between the thread that modifies the stack limit and the thread that is checking its stack. That means that there is some indeterminacy in how long it will take for the change to be seen, particularly on the ARM with its weak memory ordering.
Regards, David