Tom Lane wrote:
>
> 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;
But it seems what your scheme(ImmediateInterruptOK) requires.
> > 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 ;-).
You made a supplementary change first and a very
significant change second. Who would think the
first change has little meaning ? In addition I
could find no explantion about ImmediateInterruptOK
whereas there seems a nice description about
HOLD/RESUME_INTERRUPTS scheme.
>
> > 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...
Of cource I'd not like to limit the use of 'die' interrupts
for normal shutdown. However other developers seem to be
comforatable with it.
regards,
Hiroshi Inoue