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