Re: Proposal for Signal Detection Refactoring

Поиск
Список
Период
Сортировка
От Chris Travers
Тема Re: Proposal for Signal Detection Refactoring
Дата
Msg-id CAN-RpxBcdu0dg8-qVmSVKiYS2HYjaX067+3YdkwSx79agx4oug@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Proposal for Signal Detection Refactoring  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Proposal for Signal Detection Refactoring  (Chris Travers <chris.travers@adjust.com>)
Список 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 по дате отправления:

Предыдущее
От: Chris Travers
Дата:
Сообщение: Re: Proposal for Signal Detection Refactoring
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: pgbench - add pseudo-random permutation function