It’s a bit ironic that, if you optimize your code (getting rid of allocations, is a big part of that), what you want, making type stable, your code will be less responsive to interrupts (while not for sure, as you could get quicker to some other code that checks). Checking for interrupts is an unnatural thing (cooperative vs. preemptive multitasking). What other functions check, only I/O functions?
I’m not sure, should allocations check for interrupts? I recall in Java allocations, the fast path, is really fast, like just a few assembly instructions. I’m actually not sure you mean even allocations guarantee checking for interrupts (only on slow path?), rather when/if it triggers GC?
Since checking is expensive (I wasn’t sure), does it make sense to check on allocations, as you want hem fast? Or are they just even slower, so the checking is considered not relatively costly? Do you know if the checking is done on each allocation for sure?
And is this checking also done in pure C programs on allocations? I suppose allocations (there) are some of the slowest (non-I/O) library calls, so one of the few it makes sense to add the checking to.
And I’ll also add that “expensive” here doesn’t mean the operation itself take a lot of cycles to run, but such checks always have a major impact on the optimization available.
It’s hard to describe to the compiler (at least current LLVM, and no MLIR doesn’t make a difference AFAICT) that something must happen regularly, but they can happen almost anywhere, for any number of times, except that they can’t happen at some particular places.