Allow sending more kinds of objects between isolates

[mkustermann]

We would like to be able to loosen the current requirements on objects that can be sent between isolates through SendPorts. We can solve this once lightweight isolates are enabled by-default (see #36097) - which is slowly coming to its finishing line.

We want to allow sending:

• Function types (formerly #44624, #44431)
• Closures (formerly #40370)
• Generic closures (formerly #40919)
• StackTrace objects (no former issue, but lib_2/isolate/stacktrace_message_test fails)

Furthermore we want to:

• Be less ambiguous about what can and cannot be sent across SendPorts.

Once lightweight isolate support (see #36097) has been enabled by-default (probably soon), we can easily add this support.

[abobija]

Does anyone works on this? Is there any info when we will be able to send Function types?

[mkustermann]

Does anyone works on this? Is there any info when we will be able to send Function types?

Yes, we are actively working on it. We are in preparation for enabling lightweight isolates by-default (see #36097). After that doing that, allowing more object types to be sent between isolates is a piece of cake.

[lrhn]

If you can send closures, that will open up sending a lot of low-level classes, like Future and Zone (the reason you currently can't send a Future without listeners is that you can't send the Zone it contains).
Sending a Future is very likely to end up with a Future which never completes (you didn't send the completer, microtask or other future expecting to complete it).

If you send a stream pre-listening, it will include its controller and the onListen callback of that, which might risk accessing the same resource more than once.
Sending through a send port is extra-language cloning (creating an object without calling a constructor). Not all classes are suited for that. Would it be reasonable to introduce a "non-sendable" marker that you can put on classes?

There might be cases where you do want to send a primed stream to a worker isolate, to make it take over, as long as you don't use it locally, so maybe strictly making streams non-sendable isn't the best approach.
Maybe getting a "you've been cloned" callback to allow the class to disable itself would be better.

[mnordine]

There might be cases where you do want to send a primed stream to a worker isolate

Sending a Stream to an Isolate would indeed be a nice use case. See similar thinking in the JS world (Transferrable Streams):

https://www.chromestatus.com/feature/5298733486964736#details
https://github.com/whatwg/streams/blob/main/transferable-streams-explainer.md

[mkustermann]

Summary of meeting about sending closures (between @aam @lrhn and @mkustermann ):

• Already today we can send Completers, Futures, StreamControllers and Streams (as long as no listeners are installed)
• Already today we have some issues (e.g. we only re-hash VM-specific identity hashmaps/sets) - adding closure support doesn't change this.
• We don't think allowing sending of closures will indirectly allow sending of objects that are very problematic

There's a question of how much state a local closure closes over. Right now the VM's implementation closes over more state than needed (an implementation choice) that can lead to hanging on to more objects than user code can access (though a debugger might be able to access them). See e.g. #36983. Allowing sending of closures may make this "memory leak" more prominent.

In general there's no strong reservations against loosing that restriction.