[Python-Dev] Re: Intended invariants for signals in CPython

Whew. Nick, Antoine, and Chris, thanks to each of you for your feedback -- with it, I *think* I've managed to write a pure-Python signal suppression library. I'm nowhere near confident enough in its handling of corner cases yet to release it to the general public, but hopefully I'll be able to

[Python-Dev] Re: Intended invariants for signals in CPython

On Fri., 26 Jun. 2020, 7:02 am Chris Jerdonek, wrote: > On Wed, Jun 24, 2020 at 5:15 PM Yonatan Zunger via Python-Dev < > python-dev@python.org> wrote: > >> That said, the meta-question still applies: Are there things which are >> generally intended *not* to be interruptible by signals, and if

[Python-Dev] Re: Intended invariants for signals in CPython

What, weird edge cases involving *signals?* Never! :) Here's a nice simple one: it takes at least a few opcodes to set said global flag, during which (depending on the whims of how eval_break gets set) yet another signal might get raised and handled. I did just make a post to python-ideas about

[Python-Dev] Re: Intended invariants for signals in CPython

HOLY CRAP THIS IS MADNESS. I kind of love it. :) And it's related to some other problems that have been on my mind (how to "paint" stack frames with user-defined variables, with those variables then being used by things like CPU/heap profilers as smart annotations), and I have to say it's a

[Python-Dev] Re: Intended invariants for signals in CPython

I had not -- thank you! On Thu, Jun 25, 2020 at 1:49 PM Chris Jerdonek wrote: > On Wed, Jun 24, 2020 at 5:15 PM Yonatan Zunger via Python-Dev < > python-dev@python.org> wrote: > >> That said, the meta-question still applies: Are there things which are >> generally intended *not* to be

[Python-Dev] Re: Intended invariants for signals in CPython

On Wed, Jun 24, 2020 at 5:15 PM Yonatan Zunger via Python-Dev < python-dev@python.org> wrote: > That said, the meta-question still applies: Are there things which are > generally intended *not* to be interruptible by signals, and if so, is > there some consistent way of indicating this? >

[Python-Dev] Re: Intended invariants for signals in CPython

On Thu, 25 Jun 2020 11:18:13 -0700 Yonatan Zunger via Python-Dev wrote: > Also, just to sanity-check that I understand things correctly: Python > signal handlers *are* reentrant, in that a signal handler can be > interrupted by another signal, is that right? Is there any general > recommendation

[Python-Dev] Re: Intended invariants for signals in CPython

Also, just to sanity-check that I understand things correctly: Python signal handlers *are* reentrant, in that a signal handler can be interrupted by another signal, is that right? Is there any general recommendation on how to write signal handlers in order to manage that? (Antoine, I *so* wish I

[Python-Dev] Re: Intended invariants for signals in CPython

I'm taking it from this thread that suppressing signals in a small window is not something anyone in their right mind would really want to attempt. :) (Or that if they did, it would have to be through a proper change to the runtime, not something higher-level) On Thu, Jun 25, 2020 at 7:14 AM

[Python-Dev] Re: Intended invariants for signals in CPython

Le 25/06/2020 à 16:00, Guido van Rossum a écrit : > On Thu, Jun 25, 2020 at 02:02 Antoine Pitrou > wrote: > > ...  The intent, though, is that any function > waiting on an external event (this can be a timer, a socket, a > lock, a directory...) should be

[Python-Dev] Re: Intended invariants for signals in CPython

On Thu, Jun 25, 2020 at 02:02 Antoine Pitrou wrote: > ... The intent, though, is that any function > waiting on an external event (this can be a timer, a socket, a > lock, a directory...) should be interruptible so that Ctrl-C works in > an interactive prompt. > That’s not really true though

[Python-Dev] Re: Intended invariants for signals in CPython

On Wed, 24 Jun 2020 16:54:34 -0700 Yonatan Zunger via Python-Dev wrote: > ... Reading through more of the code, I realized that I greatly > underestimated the number of interruptible operations. > > That said, the meta-question still applies: Are there things which are > generally intended *not*

[Python-Dev] Re: Intended invariants for signals in CPython

... Reading through more of the code, I realized that I greatly underestimated the number of interruptible operations. That said, the meta-question still applies: Are there things which are generally intended *not* to be interruptible by signals, and if so, is there some consistent way of