<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace"><span style="font-family:arial,sans-serif">On Thu, Nov 2, 2017 at 2:22 PM, Antoine Pitrou </span><span dir="ltr" style="font-family:arial,sans-serif"><<a href="mailto:solipsis@pitrou.net" target="_blank">solipsis@pitrou.net</a>></span><span style="font-family:arial,sans-serif"> wrote:</span><br></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 1 Nov 2017 20:29:56 +0200<br>
Koos Zevenhoven <<a href="mailto:k7hoven@gmail.com">k7hoven@gmail.com</a>> wrote:<br>
><br>
> ​From a correctness point of view, that is absolutely great: if<br>
> PyErr_CheckSignals() is called, it is guaranteed to notice a new signal<br>
> regardles of how small the number of picoseconds after the `is_tripped`<br>
> flag has been set.  But is that really important?<br>
<br>
I was going to answer "no"... but actually yes.  The important case is<br>
the event loop type case:<br>
<br>
    while (1) {<br>
        select([some file descriptors]);<br>
        if (errno == EINTR) {<br>
            PyErr_CheckSignals();<br>
            if (PyErr_Occurred()) break;<br>
        }<br>
        /* continue select()ing... */<br>
    }<br>
<br>
Now say at a given point in time, no fds are actually active (or even<br>
waited for), but some signal arrives (SIGINT perhaps).<br>
select() is woken up and returns with errno EINTR.  Two things then can<br>
happen:<br>
<br>
- if PyErr_CheckSignals() notices the signal, it will run the relevant<br>
  signal handler, which may raise an exception and trigger the select()<br>
  loop to exit (e.g. SIGINT would raise KeyboardInterrupt)<br>
<br>
- if PyErr_CheckSignals() misses the signal, the loop will enter again,<br>
  and select() may sleep for an infinite amount of time<br>
<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">Oh! So that would provide a proper reason for my just-in-case decision to name the faster near-equivalent functionality PyErr_PROBE_SIGNALS instead of PyErr_CHECK_SIGNALS.</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">Cross-referencing to that (thread about making Ctrl-C "always" work):</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default"><font face="monospace, monospace"><a href="https://mail.python.org/pipermail/python-ideas/2017-November/047631.html">https://mail.python.org/pipermail/python-ideas/2017-November/047631.html</a></font><br></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div></div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Of course, what we're doing with select() above can already apply for<br>
read() or other interruptible syscalls waiting for outside data... and<br>
that pattern is present a lot internally, especially since<br>
PEP 475 ("Retry system calls failing with EINTR").<br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Now, is the "sequentially consistent" ordering on is_tripped sufficient<br>
to guarantee that signals won't be missed on a weak-ordering platform?<br>
I *think* so, but an expert would need to check that code (or we<br>
cross our fingers and wait for a hypothetical bug report).<br>
<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:monospace,monospace">I think the question is: Do we know for sure that is_trippe​d has been stored using sequentially consistent ordering prior to the call to PyErr_CheckSignals(), even if an interruptible syscall is involved? I suppose so? </div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">(But this is a separate question from the problem I was solving, of course. I'm not proposing to remove PyErr_CheckSignals())</div><div class="gmail_default" style="font-family:monospace,monospace"><br></div><div class="gmail_default" style="font-family:monospace,monospace">––Koos</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Regards<br>
<br>
Antoine.<br>
<br>
<br>
______________________________<wbr>_________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer" target="_blank">http://python.org/psf/<wbr>codeofconduct/</a><br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">+ Koos Zevenhoven + <a href="http://twitter.com/k7hoven" target="_blank">http://twitter.com/k7hoven</a> +</div>
</div></div>