Re: Interrupts vs signals

Hi,

I was chatting with Heikki about this patch and he mentioned that he recalls a
patch that did some work to unify the signal replacement, procsignal.h and
CHECK_FOR_INTERRUPTS(). Thomas, that was probably from you? Do you have a
pointer, if so?

It does seem like we're going to have to do some unification here. We have too
many different partially overlapping, partially collaborating systems here.

- procsignals - kinda like the interrupts here, but not quite. Probably can't
just merge them 1:1 into the proposed mechanism, or we'll run out of bits
rather soon. I don't know if we want the relevant multiplexing to be built
into interrupt.h or not.

Or we ought to redesign this mechanism to deal with more than 32 types of
interrupt.

- pmsignal.h - basically the same thing as here, except for signals sent *too*
postmaster.

It might or might not be required to keep this separate. There are different
"reliability" requirements...

- CHECK_FOR_INTERRUPTS(), which uses the mechanism introduced here to react to
signals while blocked, using RaiseInterrupt() (whereas it did SetLatch()
before).

A fairly simple improvement would be to use different InterruptType for
e.g. termination and query cancellation.

But even with this infrastructure in place, we can't *quite* get away from
signal handlers, because we need some way to set at the very least
InterruptPending (and perhaps ProcDiePending, QueryCancelPending etc,
although those could be replaced with InterruptIsPending()). The
infrastructure introduced with these patches provides neither a way to set
those variables in response to delivery of an interrupt, nor can we
currently set them from another backend, as they are global variables.

We could of course do InterruptsPending(~0) in in
INTERRUPTS_PENDING_CONDITION(), but it would require analyzing the increased
indirection overhead as well as the "timeliness" guarantees.

Today we don't need a memory barrier around checking InterruptPending,
because delivery of a signal delivery (via SetLatch()) ensures that. But I
think we would need one if we were to not send signals for
cancellation/terminations etc. I.e. right now the overhead of delivery is
bigger, but checking if there pending signals is cheaper.

Another aspect of this is that we're cramming more and more code into
ProcessInterrupts(), in a long weave of ifs. I wonder if somewhere along
ipc/interrupt.h there should be a facility to register callbacks to react to
delivered interrupts. It'd need to be a bit more than just a mapping of
InterruptType to callback, because of things like InterruptHoldoffCount,
CritSectionCount, QueryCancelHoldoffCount.

- timeout.c - will need a fairly big renovation for threading. IIUC Heikki is
thinking that we'll have a dedicated timer thread.

It's a lot more expensive to wake up another thread than your own. A process
local SIGALRM delivery does not require an inter processor interrupt, but
doing a pthread_sigqueue() or whatnot does. Which would be a bit silly,
because what most of the timeout handlers do is to set some variables to
true and then call SetLatch(). It might not matter *that* much, because we
don't except timeout "delivery" that frequently, but I'm also not convinced
it won't be noticeable.

Nearly all the timeouts we currently have could actually just specify the
interrupt that ought to be raised, to be sent by that timeout thread. The
one exception to that is StartupPacketTimeoutHandler() (which does
_exit(1)).

Without that one exception, a renovated timeout.c would not need to support
handlers, which would be rather nice. It's not at all obvious to me that we
actually need StartupPacketTimeoutHandler() and process_startup_packet_die()
actually need to do _exit(), we should be able to do non-blocking network IO
around these parts - at least for SSL we largely do, we just don't check for
interupts in in the right places.

Other questions:

- Can ipc/interrupts.c style interrupts be sent by postmaster? I think they
ought to before long.

Greetings,

Andres Freund