-
Notifications
You must be signed in to change notification settings - Fork 350
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
Conversation
Uint8List(_compilationIdVarint.length + protobufWriter.lengthInBytes); | ||
packet.setAll(0, _compilationIdVarint); | ||
protobufWriter.writeTo(packet, _compilationIdVarint.length); | ||
// Add one additional byte to the beginning to indicate whether or not the |
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 to IsolateChannel<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 an int
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
Uint8List(_compilationIdVarint.length + protobufWriter.lengthInBytes); | ||
packet.setAll(0, _compilationIdVarint); | ||
protobufWriter.writeTo(packet, _compilationIdVarint.length); | ||
// Add one additional byte to the beginning to indicate whether or not the |
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
Closes #2004