[Python-Dev] Questions about signal handling. (original) (raw)

Eric Snow ericsnowcurrently at gmail.com
Mon Sep 24 19:24:02 EDT 2018

On Mon, Sep 24, 2018 at 3:10 PM Yury Selivanov <yselivanov.ml at gmail.com> wrote:

On Mon, Sep 24, 2018 at 4:19 PM Eric Snow <ericsnowcurrently at gmail.com> wrote: > This matters to me because I'd like to use "pending" calls for > subinterpreters, which means dealing with signals in > PyMakePendingCalls() is problematic. Pulling the > PyErrCheckSignals() call out would eliminate that problem.

PyMakePendingCalls is a public API, even though it's not documented. If we change it to not call PyErrCheckSignals and if there are C extensions that block pure Python code execution for long time (but call PyMakePendingCalls explicitly), such extensions would stop reacting to ^C. Maybe a better workaround would be to introduce a concept of "main" sub-interpreter? We can then fix PyMakePendingCalls to only check for signals when it's called from the main interpreter.

I'm planning on making Py_MakePendingCalls() a backward-compatible wrapper around a new private _Py_MakePendingCalls() which supports per-interpreter operation. Then the eval loop will call the new internal function. So nothing would change for users.

-eric

More information about the Python-Dev mailing list