New submission from STINNER Victor <vstin...@python.org>:
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?
----------
components: Interpreter Core
messages: 383901
nosy: vstinner
priority: normal
severity: normal
status: open
title: Review usage of atomic variables in signamodule.c
versions: Python 3.10
_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue42767>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
