Author vstinner
Recipients eric.snow, vstinner
Date 2020-04-08.21:33:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1586381605.22.0.272292107555.issue40231@roundup.psfhosted.org>
In-reply-to
Content
Currently, _Py_ThreadCanHandlePendingCalls() only returns true if the current thread is the Python "main thread" (_PyRuntime.main_thread).

_PyRuntime.main_thread is initialized by _PyRuntime_Initialize().

The problem is that a subinterpreter can run a separated thread which may not be the "main thread".

As a consequence, a subinterpreter will not run schedulded pending calls, or it will run them later than it could.

I modified COMPUTE_EVAL_BREAKER() of ceval.c in bpo-40010: now if tstate->interp->ceval.pending.calls_to_do is true, tstate->interp->ceval.eval_breaker is only set to 1 if _Py_ThreadCanHandlePendingCalls() is true.

One option would be to allow any thread to run "pending calls".

Another option is to have one "main thread" per interpreter, rather than having a single "main thread" for all interpreters.


I made pending calls per-interpreter in bpo-39984.


In Python 3.7, main_thread variable came from _PyRutimeState.ceval.pending.main_thread. It was moved into _PyRuntimeState by this change:

commit 5be45a6105d656c551adeee7770afdc3b806fbb5
Author: Eric Snow <ericsnowcurrently@gmail.com>
Date:   Fri Mar 8 22:47:07 2019 -0700

    bpo-33608: Minor cleanup related to pending calls. (gh-12247)

--

_Py_ThreadCanHandleSignals() doesn't have to change: it must only return true for the main thread of the main interpreter. Currently, it's implemented as:

static inline int
_Py_ThreadCanHandleSignals(PyThreadState *tstate)
{
    return (_Py_IsMainThread() && _Py_IsMainInterpreter(tstate));
}
History
Date User Action Args
2020-04-08 21:33:25vstinnersetrecipients: + vstinner, eric.snow
2020-04-08 21:33:25vstinnersetmessageid: <1586381605.22.0.272292107555.issue40231@roundup.psfhosted.org>
2020-04-08 21:33:25vstinnerlinkissue40231 messages
2020-04-08 21:33:25vstinnercreate