Re: Proposal for Signal Detection Refactoring

On Fri, Sep 21, 2018 at 6:46 AM Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> On Thu, Sep 20, 2018 at 03:08:34PM +0200, Chris Travers wrote:
> > So here's a small patch. I will add it for the next commit fest unless
> > anyone has any reason I shouldn't.
>
> - return InterruptPending && (QueryCancelPending || ProcDiePending);
> + return PENDING_INTERRUPT_LEVEL() >= QUERY_CANCEL;
>
> This is pretty similar to lock levels, where it is pretty hard to put a
> strict monotone hierarchy when it comes to such interruptions.

I understand how lock levels don't fit a simple hierarchy but at least when
it comes
to what is going to be aborted on a signal, I am having trouble
understanding the problem here.

Does anyone have any search terms I should look into the archives regarding
this issue?

I will assume this patch will be rejected then.

> The new
> code does not seem like an improvment either, as for example in the code
> mentioned above, you know directly what are the actions involved, which
> is not the case with the new code style.
>

The initial motivation for this patch was that it felt a little bit odd to
be using global
boolean flags for this sort of approach and I was concerned that if this
approach
proliferated it might cause problems later. As far as I know my previous
patch was
the second use of the current pattern.

So one thing I wonder is if there are ways where abstracting this would
make more sense.

> --
> Michael
>

--
Best Regards,
Chris Travers
Head of Database

Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com
Saarbrücker Straße 37a, 10405 Berlin