Message383901
In bpo-41713, I ported the _signal module to the multi-phase initialization API. I tried to move the signal state into a structure to cleanup the code, but I was scared by the following atomic variables:
---------------
static volatile struct {
_Py_atomic_int tripped;
PyObject *func;
} Handlers[NSIG];
#ifdef MS_WINDOWS
#define INVALID_FD ((SOCKET_T)-1)
static volatile struct {
SOCKET_T fd;
int warn_on_full_buffer;
int use_send;
} wakeup = {.fd = INVALID_FD, .warn_on_full_buffer = 1, .use_send = 0};
#else
#define INVALID_FD (-1)
static volatile struct {
#ifdef __VXWORKS__
int fd;
#else
sig_atomic_t fd;
#endif
int warn_on_full_buffer;
} wakeup = {.fd = INVALID_FD, .warn_on_full_buffer = 1};
#endif
/* Speed up sigcheck() when none tripped */
static _Py_atomic_int is_tripped;
---------------
For me, the most surprising part is Handlers[signum].tripped which is declared as volatile *and* an atomic variable.
I'm not sure if Handlers[signum].func must be volatile neither.
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"?
--
I recently added pycore_atomic_funcs.h which provides functions to access variables atomically. It uses atomic functions if available, or falls back on "volatile" otherwise. Maybe this approach would be interesting here, maybe for Handlers[signum].func? |
|
Date |
User |
Action |
Args |
2020-12-28 16:06:14 | vstinner | set | recipients:
+ vstinner |
2020-12-28 16:06:14 | vstinner | set | messageid: <1609171574.21.0.863053109272.issue42767@roundup.psfhosted.org> |
2020-12-28 16:06:14 | vstinner | link | issue42767 messages |
2020-12-28 16:06:13 | vstinner | create | |
|