cc @lexprfuncall.
Set owner to @rakudrama.
Added Area-DOM, Triaged labels.

Removed Area-DOM label.
Added Area-HTML label.

I don't expect we'll get to this before M1, so marking as later.

In JS, background isolates are just workers, so we should be able to leverage window.postMessage (on browsers where transferable is supported). In Dartium, we'd need another way to do this I think. Thoughts?

cc @rakudrama.
Removed the owner.

Added this to the Later milestone.

This comment was originally written by schwa...@gmail.com

It actually looks pretty straightforward, at least from Dart-to-Dart. Only a handful of object-types will support the Transferable interface. Let's consider ArrayBuffer... how is this implemented in V8? I assume there is a special JS object that lives on the V8 heap that contains a non-accessible pointer to the ArrayBuffer payload on the C heap. Transferring to/from another worker consists of:

• creating a new ArrayBuffer JS object that will be accessible in the destination
• filling in the pointer to point at the same payload as the original ArrayBuffer
• "neutering" the original ArrayBuffer by setting its C-heap pointer to NULL

I doubt that the existing V8 implementation could be shared, but I imagine the port to Dart would largely be transcription to Dart's embedding-API.

In this scheme, it would also be possible to transfer Transferable objects between V8 and Dart, in much the same way. Some details would need to be handled, like ensuring that the source and destination objects are pinned during the transfer operation (i.e. no GCs); I'm not sure whether the embedding APIs support this easily.

The more difficult case is what to do about sending regular objects between V8 and Dart, since their object-models are so different. Perhaps a JS object could be transformed into a Dart Map whose values are other Maps (corresponding to regular JS objects), or other types corresponding to the JS types (such as String or double). In the other direction, only a such a Dart map could be sent... if it contains instances of class other than the allowed few, an exception would be thrown. But I digress...

This comment was originally written by sc...@gmail.com

Just wanted to emphasize that I didn't intend to trivialize this... I remember looking at the changes required to enable multi-VM support in WebKit, and understand that this is all much harder in reality than it is conceptually.

Added Library-Isolates label.

Added Library-Isolate label.

Removed Library-Isolates label.

Transferables should be working now.

Added AssumedStale label.

This comment was originally written by @pjako

Have not seen any changes to this in the commits to the VM, transferables don't work, at least when dart runs on the DartVM.

This comment was originally written by @pjako

One year later... is this feature still on the table?

This comment was originally written by @mezoni

One year later... is this feature still on the table?

One year is not a three years.
Please, wait again...
...one year.

Are transferable objects supported by Dart now? Chrome 17+ and Firefox 18+ supports them based on https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers

I believe it works when compiled to JS. I suspect it doesn't work between Dart isolates, as that would have nothing to do with the browser implementation. But for performance optimization, presumably what's more important is the production version.

Not sure about DartVM, but as of 1.20, dart2js version of SendPort.send() doesn't support transferable objects.