When reporting illegal object SendPort.send should print retaining path and hide implementation internal classes

[dnfield]

See e.g. simolus3/drift#2279 (comment)

 dart test test/isolate_test.dart
00:01 +8 -1: in same isolate with explicit serialization can run deletes, updates and batches [E]                                                                                                                                                                                                                    
  Invalid argument(s): Illegal argument in isolate message: (object is a SuspendState)
  dart:isolate                   Isolate.run
  test/isolate_test.dart 255:19  _runTests.<fn>

I don't know where SuspendState is defined. It's not defined in Drift AFAICT, and I don't see it when I search on api.dart.dev.

So basically, I don't really know what's wrong or where to start with fixing this issue.

[alexmarkov]

This error likely indicates that you're trying to send a Future returned from a suspended async function to another isolate.
We should detect this case explicitly and throw an error with a more detailed explanation message.

[simolus3]

Possibly also related to #48592.

[a-siva]

//cc @aam

[dnfield]

This error likely indicates that you're trying to send a Future returned from a suspended async function to another isolate. We should detect this case explicitly and throw an error with a more detailed explanation message.

Can you explain a bit more about why that doesn't work and what should be done instead?

[alexmarkov]

Future represents a result of asynchronous computation which is happening within a certain isolate. An ability to await for the completion of that computation and get its result from another isolate would bypass message passing and violate isolation. Sending non-constant objects between isolates involve copying them, so even if we could send futures, the receiving isolate would get its own copy of a Future, which will not be completed by the original asynchronous computation and will not get its result.

Internally, SuspendState object represents a stack frame for a suspended asynchronous computation. It is not useful to make a copy of SuspendState in another isolate, as it can only be resumed within the original isolate.

[mraleph]

I think there are two parts here:

• When reporting illegal object in the message SendPort.send should print retaining path to making finding illegal object simpler
• When reporting some implementation internal object (like SuspendState) we should abort sending earlier and report a clear error message

/cc @aam @mkustermann

I think we are definetely overdue to fix this error message. I even thought we might have an issue already tracking this work - but I could not find it.

Would it be something you could look at @aam?

PS. I also think that there is an interesting question around sending Stream and Future instances to another isolate. I have previously suggested that sending a Future through SendPort should establish a channel between two isolates, e.g. if the code awaits the Future on the receiving side then the Future will be awaited on the sending side as well and completion should be forwarded through the port. Similar with Stream. Though @lrhn suggested that doing this automatically is a bit too much magic - and maybe instead we should just have utility classes which do this.

[mkustermann]

I even thought we might have an issue already tracking this work - but I could not find it.

Maybe you were looking for #48592?

[lrhn]

Creating an automatic channel between two isolates when sending a stream or future is too-much-magic mainly because it requires an open receive port in one or both directions. These ports are implicit so users have no way to close them, and if they did, no way to know when to close them.

If the VM can do something magic under the hood, where a _Future serialized to another isolate would create implicit connections that won't keep any isolate alive, and which know when the other end stops being relevant, then that'd probably be safe. But if we can do that, there's so many other things I'd like to use such connections for, to the point where I'd deliberately send futures and streams around to create such connections :)

[alexmarkov]

Automatically synchronizing Futures/Streams between isolates makes isolates less isolated. Maybe this should be done through a separate new API, only for a new kind of Future/Stream (SharedFuture, SharedStream etc) so it would only happen if user explicitly asked for such synchronization.

Also, if we're willing to breach isolation and open more communication channels between isolates, then we should also consider creating collections which are automatically updated when modified from another isolate (SharedList, SharedMap, SharedSet etc).