Re: Interrupts vs signals

On 20/02/2026 16:22, Heikki Linnakangas wrote:
> 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.

Here's another rebase, no other changes.

- Heikki