Re: Interrupts vs signals

On Sat, Nov 23, 2024 at 10:58 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> Hmm, so this would replace the maybeSleepingOnInterrupts bitmask I
> envisioned. Makes a lot of sense. If it's a single bit though, that
> means that you'll still get woken up by interrupts that you're not
> waiting for. Maybe that's fine. Or we could merge the
> maybeSleepingOnInterrupts and pendingInterrupts bitmasks to a single
> atomic word, so that you would have a separate "maybe sleeping" bit for
> each interrupt bit, but could still use atomic_fetch_or atomically read
> the interrupt bits and announce the sleeping.

I think one bit is fine for now.  At least, until we have a serious
problem with interrupts arriving when you're sleeping but not ready to
service that particular interrupt.  The 'interrupt bit already set,
don't try to wake me' stuff discussed earlier would limit the number
of useless wakeups to one, until you eventually are ready and consume
the interrupt.  The main case I can think of, if we fast forward to
the all-procsignals-become-interrupts patch (which I'll be rebasing on
top of this when the next version appears), is that you might receive
a sinval catchup request, but you might be busy running a long query.
Sinval catchup messages are only processed between queries, so you
just keep ignoring them until end of query.  I think that's fine, and
unlikely.  Do you have other cases in mind?

If there is legitimate use case for a more fine-grained maybe-sleeping
and I've been too optimistic above, I don't think we should give one
whole maybe-sleeping bit to each interrupt reason.  We only have 32
bit atomics (splinlock-based emulation of 64 bit atomics is not good
enough for this, it's not safe in SIGALRM handlers, at least not
without a lot more pain; admittedly the SIGALRM handlers should
eventually be replaced but not for a while) so if we used up two bits
for every interrupt reason we could handle only 16 interrupt reasons,
and that's already not enough.  Perhaps we could add maybe-sleeping
bits for classes of interrupt if we ever determine that one bit for
all of them isn't enough?