Re: Proposal for Signal Detection Refactoring - Mailing list pgsql-hackers

From Chris Travers
Subject Re: Proposal for Signal Detection Refactoring
Date
Msg-id CAN-RpxBcdu0dg8-qVmSVKiYS2HYjaX067+3YdkwSx79agx4oug@mail.gmail.com
Whole thread Raw
In response to Re: Proposal for Signal Detection Refactoring  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Proposal for Signal Detection Refactoring  (Chris Travers <chris.travers@adjust.com>)
List pgsql-hackers


On Tue, Sep 25, 2018 at 3:23 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Chris Travers <chris.travers@adjust.com> writes:
> However,  what I think one could do is use a struct of volatile
> sig_atomic_t members and macros for checking/setting.  Simply writing a
> value is safe in C89 and higher.

Yeah, we could group those flags in a struct, but what's the point?

This was one of two things I noticed in my previous patch on interrupts and loops where I wasn't sure what the best practice in our code is.

If we don't want to make this change, then would there be any objection to me writing up a README describing the flags, and best practices in terms of checking them in our code based on the current places we use them?  If the current approach will be unlikely to change in the future, then at least we can document that the way I went about things is consistent with current best practices so next time someone doesn't really wonder.
 

                        regards, tom lane


--
Best Regards,
Chris Travers
Head of Database

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

pgsql-hackers by date:

Previous
From: Chris Travers
Date:
Subject: Re: Proposal for Signal Detection Refactoring
Next
From: Fabien COELHO
Date:
Subject: Re: pgbench - add pseudo-random permutation function