Re: Proposal for Signal Detection Refactoring
От | Chris Travers |
---|---|
Тема | Re: Proposal for Signal Detection Refactoring |
Дата | |
Msg-id | CAN-RpxCNBuyDPkpKKxqdYdig4+71JhxTXMa8uOToO-=5T0sLVw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal for Signal Detection Refactoring (Chris Travers <chris.travers@adjust.com>) |
Список | pgsql-hackers |
Very minor revision
On Mon, Sep 24, 2018 at 11:45 AM Chris Travers <chris.travers@adjust.com> wrote:
Ok so having looked into this a bit more....It looks like to be strictly conforming, you can't just use a series of flags because neither C 89 or 99 guarantee that sig_atomic_t is read/write round-trip safe in signal handlers. In other words, if you read, are pre-empted by another signal, and then write, you may clobber what the other signal handler did to the variable. So you need atomics, which are C11....What I would suggest instead at least for an initial approach is:1. A struct of volatile bools statically stored
These would be implemented as sig_atomic_t which is defined in C89 but has no atomic operators other than writing the full value.
2. macros for accessing/setting/clearing flags3. Consistent use of these macros throughout the codebase.To make your solution work it looks like we'd need C11 atomics which would be nice and maybe at some point we decide to allow newer feature, or we could wrap this itself in checks for C11 features and provide atomic flags in the future. It seems that the above solution would strictly comply to C89 and pose no concurrency issues.--Best Regards,Chris TraversHead of DatabaseSaarbrücker Straße 37a, 10405 Berlin--Best Regards,Chris TraversHead of DatabaseSaarbrücker Straße 37a, 10405 Berlin
Best Regards,
Chris Travers
Head of Database
Saarbrücker Straße 37a, 10405 Berlin
В списке pgsql-hackers по дате отправления: