Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> I think the much more significant change is the following
> one not the above one.
Well, yes; the "above" change was just a last-gasp attempt to make the
old scheme work, whereas the "following" change introduced the new
scheme.
But there is no way that we can allow proc_exit to be invoked at any
random instant; it has to be constrained to places where all the
infrastructure state is consistent. (Or at least all the state of
the infrastructure modules that proc_exit will invoke. But that
covers an awful lot of territory.)
In particular, since routines invoked during proc_exit rely on both
shared and private state, I don't believe it can be safe to allow
proc_exit at any spinlock boundary. We could possibly make it safe
by introducing enough HOLD/RESUME_INTERRUPTS calls --- but that
direction requires that we be forever vigilant to ensure that we've
locked interrupts everywhere we have to; and there's no way to notice
if we've failed to. I'd much rather take the other approach of allowing
the interrupt only at certain specified spots. The failure mode here is
that a cancel/die interrupt doesn't get handled as soon as you'd like.
I consider that better than the failure mode of the other approach,
which could be undetected data corruption.
regards, tom lane