Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bpo-39984: Move pending calls to PyInterpreterState #19066

Merged
merged 1 commit into from Mar 19, 2020

Conversation

@vstinner
Copy link
Member

@vstinner vstinner commented Mar 19, 2020

If Py_AddPendingCall() is called in a subinterpreter, the function is
now scheduled to be called from the subinterpreter, rather than being
called from the main interpreter.

Each subinterpreter now has its own list of scheduled calls.

  • Move 'pending 'and 'eval_breaker' fields from _PyRuntimeState.ceval
    to PyInterpreterState.ceval.
  • new_interpreter() now calls _PyEval_InitThreads() to initialize
    pending calls (create the lock on pending calls).
  • Fix Py_AddPendingCall() for subinterpreters. It now calls
    _PyThreadState_GET() which works in a subinterpreter if the
    caller holds the GIL, and only falls back on
    PyGILState_GetThisThreadState() if _PyThreadState_GET()
    returns NULL.

https://bugs.python.org/issue39984

If Py_AddPendingCall() is called in a subinterpreter, the function is
now scheduled to be called from the subinterpreter, rather than being
called from the main interpreter.

Each subinterpreter now has its own list of scheduled calls.

* Move 'pending 'and 'eval_breaker' fields from _PyRuntimeState.ceval
  to PyInterpreterState.ceval.
* new_interpreter() now calls _PyEval_InitThreads() to initialize
  pending calls (create the lock on pending calls).
* Fix Py_AddPendingCall() for subinterpreters. It now calls
  _PyThreadState_GET() which works in a subinterpreter if the
  caller holds the GIL, and only falls back on
  PyGILState_GetThisThreadState() if _PyThreadState_GET()
  returns NULL.
@vstinner
Copy link
Member Author

@vstinner vstinner commented Mar 19, 2020

If a subinterpreter running in a thread gets a signal, SIGNAL_PENDING_SIGNALS() sets signals_pending to 1 and eval_breaker to 1. In this case, subinterpreter calls handle_signals(), but since it's not the main thread, it does nothing and signals_pending value remains 1.

Later, when the main interpreter will run in the main thread, COMPUTE_EVAL_BREAKER() sets eval_breaker to 1 and so handle_signals() will be called. Finally, signals are handled, and signals_pending is reset to 0.

In short, this PR changes should not break signal handling.

But it's unclear to me what happens with eval_break value when handle_signals() is called in a thread different than the main thread or in a subinterpreter. Will the thread "break" the ceval loop at each instruction to call handle_signals()? Is eval_break value reset to 0? If yes, when?

@vstinner
Copy link
Member Author

@vstinner vstinner commented Mar 19, 2020

Signal handling is inefficient in multithreaded applications: I created https://bugs.python.org/issue40010 to propose PR #19067 optimization.

@vstinner vstinner merged commit 50e6e99 into python:master Mar 19, 2020
9 checks passed
9 checks passed
Docs
Details
Windows (x86)
Details
Windows (x64)
Details
macOS
Details
Ubuntu
Details
Azure Pipelines PR #20200319.2 succeeded
Details
bedevere/issue-number Issue number 39984 found
Details
bedevere/news News entry found in Misc/NEWS.d
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@vstinner vstinner deleted the vstinner:subinterp_pending_calls branch Mar 19, 2020
vegerot added a commit to vegerot/cpython that referenced this pull request Jun 10, 2020
If Py_AddPendingCall() is called in a subinterpreter, the function is
now scheduled to be called from the subinterpreter, rather than being
called from the main interpreter.

Each subinterpreter now has its own list of scheduled calls.

* Move pending and eval_breaker fields from _PyRuntimeState.ceval
  to PyInterpreterState.ceval.
* new_interpreter() now calls _PyEval_InitThreads() to create
  pending calls lock.
* Fix Py_AddPendingCall() for subinterpreters. It now calls
  _PyThreadState_GET() which works in a subinterpreter if the
  caller holds the GIL, and only falls back on
  PyGILState_GetThisThreadState() if _PyThreadState_GET()
  returns NULL.
vegerot added a commit to vegerot/cpython that referenced this pull request Jun 10, 2020
If Py_AddPendingCall() is called in a subinterpreter, the function is
now scheduled to be called from the subinterpreter, rather than being
called from the main interpreter.

Each subinterpreter now has its own list of scheduled calls.

* Move pending and eval_breaker fields from _PyRuntimeState.ceval
  to PyInterpreterState.ceval.
* new_interpreter() now calls _PyEval_InitThreads() to create
  pending calls lock.
* Fix Py_AddPendingCall() for subinterpreters. It now calls
  _PyThreadState_GET() which works in a subinterpreter if the
  caller holds the GIL, and only falls back on
  PyGILState_GetThisThreadState() if _PyThreadState_GET()
  returns NULL.
gmelikov added a commit to gmelikov/cpython that referenced this pull request Aug 22, 2020
If Py_AddPendingCall() is called in a subinterpreter, the function is
now scheduled to be called from the subinterpreter, rather than being
called from the main interpreter.

Each subinterpreter now has its own list of scheduled calls.

* Move pending and eval_breaker fields from _PyRuntimeState.ceval
  to PyInterpreterState.ceval.
* new_interpreter() now calls _PyEval_InitThreads() to create
  pending calls lock.
* Fix Py_AddPendingCall() for subinterpreters. It now calls
  _PyThreadState_GET() which works in a subinterpreter if the
  caller holds the GIL, and only falls back on
  PyGILState_GetThisThreadState() if _PyThreadState_GET()
  returns NULL.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
You can’t perform that action at this time.