Re: Interrupts vs signals

On 18/02/2026 02:11, Heikki Linnakangas wrote:
> On 14/02/2026 23:56, Andres Freund wrote:
>> Could we have the mask of interrupts that WaitInterrupt() is waiting
>> for in a
>> second variable? That way we could avoid interrupting WaitInterrupt()
>> when
>> raising or sending a signal that WaitInterrupt() is not waiting for.
>> I think
>> that can be one race-freely with a bit of care?
>
> Yeah, I thought of that, but I'm not sure what the right tradeoff here
> is. I doubt the spurious wakeups matter much in practice. Then again,
> maybe it's not much more complicated, so maybe I should try that.
>
> Now with this new version, the same consideration applies to the
> CFI_ATTENTION flag I added. We could expose a process's
> CheckForInterruptsMask alongside the pending interrupts, so it would be
> SendInterrupt()'s responsibility to check if the receiving backend's
> CheckForInterruptsMask includes the interrupt that's being sent. That
> would similarly eliminate the "false positive" ProcessInterrupts() calls
> from CHECK_FOR_INTERRUPTS(), by moving the logic to the senders. The
> SLEEPING_ON_INTERRUPTS and CFI_ATTENTION flags are quite symmetrical.

I tried that approach, exposing an "attention bitmask" where a backend
advertises which interrupts it's currently interested in. I think I like it.

Patch attached. The relevant changes for this "attention mechanism" are
in the last patch, but there are some other small changes too so this
split into patches is a little messy. I moved the list of standard
interrupts to a separate header file, for example. So for reviewing, I
recommend reading the resulting interrupt.h and interrupt.c files after
applying all the patches, instead of trying to read the diff for those.

- Heikki