Re: Proposal for Signal Detection Refactoring

From: Chris Travers <chris(dot)travers(at)adjust(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: michael(at)paquier(dot)xyz, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Proposal for Signal Detection Refactoring
Date: 2018-09-26 07:54:36
Message-ID: CAN-RpxBcdu0dg8-qVmSVKiYS2HYjaX067+3YdkwSx79agx4oug@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 25, 2018 at 3:23 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Chris Travers <chris(dot)travers(at)adjust(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2018-09-26 08:26:41 Re: pgbench - add pseudo-random permutation function
Previous Message Chris Travers 2018-09-26 07:50:00 Re: Proposal for Signal Detection Refactoring