Use thread lock to support comms via subshells #603
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The upcoming
ipykernel7.0.0 release will support subshells which are separate threads of execution within a kernel process. JupyterLab has already been updated to deal with subshells on kernels that support them and this includes options for running comms over subshells (jupyterlab/jupyterlab#17363). This PR contains changes that are needed inipymplto support subshells, specifically use of athreading.Lockin the python code that accesses global state such at Matplotlib'sGcfandipython.display. Without this we see problems such as plots not being displayed as one thread can be, for example, modifying a collection inGcfwhilst another is reading it. Strictly speaking we only need to lock when one thread is writing to a global as we can tolerate multiple non-modifying reads at the same time, but I have preferred to keep the changes as simple and understandable as possible but putting the locks at a high level in each of the functions that needs it.Above is a screenshot reproducing the problem using latest commit 5e068ed, showing that the third plot is not displayed. To reproduce this use the latest
jupyterlaband preciselyipykernel==7.0.0a2, and in Lab's Settings Editor select "Kernel comms over subshells" to be "One subshell per comm-target". It does not occur every time, but this is the setting that I have found most likely to produce the problem. After this PR, all plots display correctly.