On Mon, Sep 24, 2018 at 3:10 PM Yury Selivanov <yselivanov...@gmail.com> wrote: > On Mon, Sep 24, 2018 at 4:19 PM Eric Snow <ericsnowcurren...@gmail.com> wrote: > > This matters to me because I'd like to use "pending" calls for > > subinterpreters, which means dealing with signals *in* > > Py_MakePendingCalls() is problematic. Pulling the > > PyErr_CheckSignals() call out would eliminate that problem. > > Py_MakePendingCalls is a public API, even though it's not documented. > If we change it to not call PyErr_CheckSignals and if there are C > extensions that block pure Python code execution for long time (but > call Py_MakePendingCalls 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 Py_MakePendingCalls 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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
