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.
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.
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.
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.
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.
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