Add operator to ensure notifications are emitted inside the GIL #11
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.
This PR adds initial support for explicitly controlling the state of the global interpreter lock. In preparation for Python 3.12 sub-interpreters, we decided to remove implicit locking throughout the scripting library. This meant instead introducing support for locking and releasing the GIL.
Since we expect most scripting operations to be called in tandem with workflow notifications, it is enough to lock the GIL during the call to
OnNext, which can be implemented as a general wrapper (ObserveOnGIL) around any observable sequence.Finally, to minimize the need for explicit locking, this PR also moves emission of the runtime upon creation inside the GIL, so initialization operators can be chained directly without explicitly grabbing the interpreter lock. A new operator
GetRuntimeis also introduced to retrieve the runtime manager and re-emit it inside the GIL for deferred operations. This pattern may be generalized in the future to sub-interpreters or modules as necessary.Fixes #10