This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ammar2
Recipients ammar2, corona10, shihai1991, vstinner
Date 2020-12-28.19:57:57
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1609185477.55.0.527731732658.issue42767@roundup.psfhosted.org>
In-reply-to
Content
> For me, the most surprising part is Handlers[signum].tripped which is declared as volatile *and* an atomic variable.

I think it's just following this part of the C spec (Some background in bpo-12060):

> or refers to any object with static storage duration other than by assigning a value to a static storage duration variable of type volatile sig_atomic_t. Furthermore, if such a call fails, the value of errno is unspecified.

https://pubs.opengroup.org/onlinepubs/007904875/functions/sigaction.html / https://wiki.sei.cmu.edu/confluence/display/c/SIG31-C.+Do+not+access+shared+objects+in+signal+handlers

> I'm not sure if Handlers[signum].func must be volatile neither.

I think your assessment here is right considering it's never used in the signal handler itself.

> Also, wakeup.fd is declared as sig_atomic_t on Unix. Could we use an atomic variable instead, or is it important to use "sig_atomic_t"?

Again looking at the https://wiki.sei.cmu.edu/confluence/display/c/SIG31-C.+Do+not+access+shared+objects+in+signal+handlers recommendation it seems like using an atomic variable is fine but only if it's lock-free.
History
Date User Action Args
2020-12-28 19:57:57ammar2setrecipients: + ammar2, vstinner, corona10, shihai1991
2020-12-28 19:57:57ammar2setmessageid: <1609185477.55.0.527731732658.issue42767@roundup.psfhosted.org>
2020-12-28 19:57:57ammar2linkissue42767 messages
2020-12-28 19:57:57ammar2create