On Wed, 1 Nov 2017 20:29:56 +0200 Koos Zevenhoven <k7ho...@gmail.com> wrote: > > ​From a correctness point of view, that is absolutely great: if > PyErr_CheckSignals() is called, it is guaranteed to notice a new signal > regardles of how small the number of picoseconds after the `is_tripped` > flag has been set. But is that really important?
I was going to answer "no"... but actually yes. The important case is the event loop type case: while (1) { select([some file descriptors]); if (errno == EINTR) { PyErr_CheckSignals(); if (PyErr_Occurred()) break; } /* continue select()ing... */ } Now say at a given point in time, no fds are actually active (or even waited for), but some signal arrives (SIGINT perhaps). select() is woken up and returns with errno EINTR. Two things then can happen: - if PyErr_CheckSignals() notices the signal, it will run the relevant signal handler, which may raise an exception and trigger the select() loop to exit (e.g. SIGINT would raise KeyboardInterrupt) - if PyErr_CheckSignals() misses the signal, the loop will enter again, and select() may sleep for an infinite amount of time Of course, what we're doing with select() above can already apply for read() or other interruptible syscalls waiting for outside data... and that pattern is present a lot internally, especially since PEP 475 ("Retry system calls failing with EINTR"). Now, is the "sequentially consistent" ordering on is_tripped sufficient to guarantee that signals won't be missed on a weak-ordering platform? I *think* so, but an expert would need to check that code (or we cross our fingers and wait for a hypothetical bug report). Regards Antoine. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/