draft: fix execution lock in session #853
Draft
Conversation
This file contains 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
bjchambers
reviewed
Nov 8, 2023
| @@ -13,15 +13,15 @@ use crate::error::{ErrorContext, IntoError, Result}; | |||
| #[pyclass] | |||
| #[derive(Clone)] | |||
| pub(crate) struct Execution { | |||
| execution: Arc<Mutex<Option<RustExecution>>>, | |||
| execution: Arc<Option<RustExecution>>, | |||
There was a problem hiding this comment.
Given the difficulties, it seems like we may be better off having submitting an execution return a pair of Execution, StopChannel. Then we can leave the mutex in the execution code, but interact with the stop channel without locking it. Thoughts?
There was a problem hiding this comment.
Yeah, I guess so 😞 . I'll try that route
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.
Still issues around
sendingthe future across threads, I think. Also had to use thetokio::sync::Mutexin order to hold the lock across theawait, but I'm not sure that this is the correct pattern we should follow, as it may still result in a deadlock if we never receive a new batch fromnext.