Re: Proposal for Signal Detection Refactoring

On 2018-09-25 08:57:25 +0900, Michael Paquier wrote:
> On Mon, Sep 24, 2018 at 10:06:40AM -0700, Andres Freund wrote:
> > This doesn't seem to solve an actual problem, why are we discussing
> > changing this? What'd be measurably improved, worth the cost of making
> > backpatching more painful?
> 
> My point was just to reduce the number of variables used and ease
> debugger lookups with what is on the stack.

I'm not sure a bitflag really gives you that - before gdb gives you the
plain value, afterwards you need to know the enum values and do bit math
to know.


> Anyway, putting the back-patching pain aside, and just for my own
> knowledge...  Andres, would it be fine to just use one sig_atomic_t
> field which can be set from different code paths?  Say:
> typedef enum SignalPendingType {
>     PENDING_INTERRUPT,
>     PENDING_CANCEL_QUERY,
>     PENDING_PROC_DIE,
>     PENDING_RELOAD,
>     PENDING_SESSION_TIMEOUT
> };

Well, they'd have to different bits...


> extern volatile sig_atomic_t signalPendingFlags;

Note that sig_atomic_t IIRC is only guaranteed to effectively be 8 bit
wide - so you couldn't have that many flags.


Greetings,

Andres Freund