-
Notifications
You must be signed in to change notification settings - Fork 30
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
Use a task queue to ensure code blocks are executed sequentially #510
Use a task queue to ensure code blocks are executed sequentially #510
Conversation
This ensures that all of the blocks are sent over in a single sequential batch, with no way for anyone else to execute their own block between two of ours, which would cause ordering issues
While I have not tested it, I believe this problem also exists for the Jupyter executor, as it also quarto/apps/vscode/src/host/executors.ts Lines 63 to 78 in 06678d5
|
Since this is tricky to get right, it seems like vsc-quarto should be in charge of executing the commands so that it can make sure these are run "atomically", i.e. all commands are run before yielding back to the event loop. To this end there could be a new API where language extensions provide an |
await
on the last code block
(just letting you know that this change looks a lot safer now, from what I can tell!) |
@cscheid that's great to hear! Yea I think this is a much saner approach. I've also realized that this is a problem in more than Positron #509 (comment), so I've devised |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like this new setup!
I think we could use an existing async queue? In the positron-r
extension we use PQueue.
Lmao at the fact that I implemented this from scratch
@lionel- it seems like PQueue was actually exactly what we needed. I took a look at their implementation and it seems extremely similar to my |
Closes #509
Joint work with @lionel-
This ensures that all of the blocks are sent over in a single sequential batch, with no way for anyone else to execute their own block between two of ours, which would cause ordering issues