Hi,I have been chatting with Martin about this and we think that it might be much safer if we stop neutering the array that is being transferred, and instead just keep it attached on the sending side.A lot of code has been written pervasively with the assumption that the length does not change - so we have hard time predicting whether or not we fix all of them. This introduces potential for hard to debug bugs and security issues.It seems much safer to simply introduce a reference count into the backing store of the transferrable array (which should probably be called shareble) and increment this reference count once we share it with another isolate.We can simply specify that concurrent accesses to the backing store have undefined behavior.
Isolates are specified as communicating only via message passing. An implementation of typed data that creates a shared memory communication channel is not permitted.
To me this seems like a much safer approach: we get benefits of cheap memory transfer and at the same time we reduce possibility of bugs considerably, because old invariants still continue to hold.Note that embedders were always free to create such "shared" arrays pointing to the same memory - so we don't really introduce something new that was not possible before.
While it has been possible for an embedder to create a shared array because the VM does not check, I maintain this a bug in the embedder. The embedder is also responsible for maintaining the actor model, both for typed data like this and not exposing global state through native functions.
is https://dart-review.googlesource.com/c/sdk/+/86640/1..25/runtime/lib/typed_data.cc#206 what you had in mind regarding adding a check for null-pointer typed data?
Hi Alex,Yes and you would also need to make similar change to LoadUntaggedInstr code pattern so that optimized code handles it correctly as well.