Re: Proposal for Signal Detection Refactoring

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Chris Travers <chris(dot)travers(at)adjust(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Proposal for Signal Detection Refactoring
Date: 2018-09-25 01:02:09
Message-ID: 20180925010209.GC1354@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Sep 24, 2018 at 05:23:56PM -0700, Andres Freund wrote:
> On 2018-09-25 08:57:25 +0900, Michael Paquier wrote:
>> 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...

Sure, I forgot to write the "foo = 1 << 0" and such ;)

>> 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.

I see. I thought that it mapped at least int, but C99 tells that it
can be as small as char. That's indeed quite limited...
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-09-25 01:03:49 Re: Proposal for Signal Detection Refactoring
Previous Message Michael Paquier 2018-09-25 00:58:07 Re: Revoke execution permission of pg_stat_statements_reset() from pg_read_all_stats role