Fix Isolate.spawn for hot reload case after issue 6610 is fixed #35302
Labels
area-vm
Use area-vm for VM related issues, including code coverage, and the AOT and JIT backends.
closed-obsolete
Closed as the reported issue is no longer relevant
When issue #6610 was first created we did not have the 'hot reload' feature, I think it is worth discussing the implications of hot-reloading and using the 'Isolate.spawn' API to spawn child isolates
If we spawn child isolates using the Isolate.spawn API and then hot reload the parent isolate or a child isolate we could potentially have isolates running different versions of the app and any messages passed consisting non primitive types could result in weird behavior
if we spawn a child isolate after a hot reload should it use the newly modified app script or the original one?
Getting this right in all situations would require having some kind of check pointing and getting all the isolates in the group reloaded with the new modified source. I don't believe it is worth spending engineering cycles trying to implement this corner case.
Here is what I propose
if we spawn child isolates and then hot reload an isolate in the group then only primitive values (null, num, bool, double, String), instances of SendPort, and lists and maps whose elements are any of these will be allowed in the messages to that isolate
if a spawn is done after a hot reload is done we will spawn the child isolate using the original app script an informational message could be produced recommending a restart in this case. Again in this case only the restricted set of messages would be allowed.
The text was updated successfully, but these errors were encountered: