Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> For example I think RESUME_INTERRUPTS should
> have been
> #define RESUME_INTERRUPTS() \
> do { \
> Assert(InterruptHoldoffCount > 0); \
> InterruptHoldoffCount--; \
> ! if (ImmediateInterruptOK && InterruptPending) \
> ProcessInterrupts(); \
> } while(0)
But that's only useful if ImmediateInterruptOK is true most of the time;
which I think is far too risky an approach. We'd end up having to put
HOLD/RESUME_INTERRUPTS calls in an awful lot of places.
Right now it's true that HOLD/RESUME_INTERRUPTS isn't absolutely
necessary; we could eliminate it as long as we were very careful about
where we put CHECK_FOR_INTERRUPTS calls. However, I like having it as
an extra (and very cheap) measure of security that an interrupt won't
be accepted in critical sections of code. Basically it lets us be
slightly less worried about where the CHECK_FOR_INTERRUPTS calls can
safely go.
> In my impression 1 year ago you introduced
> 2 pretty opposed schemes in a few days.
I prefer to think of 'em as "complementary" schemes ;-).
> What I meant was to not accept 'die' interrupts immdiately
> while waiting for a lock. The lock would be released
> naturally by other backends.
That would work if we only cared about using "die" for system-wide
shutdown; but aren't you the one arguing that it should have other
uses? If I can't use "die" to kick a selected backend off a lock,
I wouldn't think retail "die" interrupts would be very useful...
regards, tom lane