Re: Proposal for Signal Detection Refactoring

On Wed, Sep 26, 2018 at 9:54 AM Chris Travers <chris(dot)travers(at)adjust(dot)com>
wrote:

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

Attaching a first draft of a readme. Feedback welcome. I noticed further
that we used to document signals and what they did with carious processes
but that this was removed after 7.0, probably due to complexity reasons.

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

--
Best Regards,
Chris Travers
Head of Database

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