-
Notifications
You must be signed in to change notification settings - Fork 351
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
Fix a race condition with re-used compilation isolate IDs #2018
Merged
Merged
Changes from 3 commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,3 +1,7 @@ | ||
## 7.1.5 | ||
|
||
* No user-visible changes. | ||
|
||
## 7.1.4 | ||
|
||
* No user-visible changes. | ||
|
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
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
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
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.
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.
It feels error-prone to push a byte into the bytearray as a completion signal for the Isolate because then the Isolate has to remember about it and remove it before sending it to the host.
Would it make sense to wrap the bytearray with another object like a custom class or a tuple to make this signal more obvious? This would require changing the
IsolateDispatcher
's input channel toIsolateChannel<MyWrapper>
, but the output channel would remain the same 🤔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.
Dart 3 Record would be a good fit for this. E.g.
IsolateChannel<(int, Uint8List)>
. On the main isolate side, you can use this to get rid of the need for sending a different "initial message" in order to send the compilationId, as you can leverage this extra int.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 considered a record-based approach, but I decided against it for a couple reasons. First, I don't like the asymmetry between sending and receiving, especially given that the
StreamChannel
API requires symmetrical types. Passing anint
that doubles as the compilation ID is a clever way around that, but ultimately moving the compilation ID out of the initial message doesn't really buy us anything—we've already got a pretty good way of providing the ID to the dispatcher isolate that doesn't require it to handle cases where it unexpectedly changes over time.There's also the question of efficiency. I haven't measured, but my assumption is that (even as a value type) instantiating and passing records is going to be somewhat more overhead than expanding the binary buffer that already exists.
Ultimately, I'm not too worried about requiring the isolate dispatcher to narrow the buffer. Two classes that have a tightly coupled protocol is a relatively common pattern in message-passing scenarios like this.
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 agree with the asymmetry concern, and with being OK with the isolate being tightly coupled (my experience working with isolates is pretty limited, but that sounds about right).
I wouldn't think the overhead would be that big, but I also didn't think appending values to a
List<T>
was expensive, and it was. 😝While I still think the pattern can be error prone, we do have tests which I think would catch a case where we forget to trim off the first byte.. I guess this is fine