0

I'm reading this article on web workers and I came across this section on Transferable Objects:

With Transferable Objects, data is transferred from one context to another. It is zero-copy, which vastly improves the performance of sending data to a Worker. Think of it as pass-by-reference if you're from the C/C++ world. However, unlike pass-by-reference, the 'version' from the calling context is no longer available once transferred to the new context.

Why? Based on my understanding of Abstract Stack Machines, it seems perfectly reasonable that original pointer can be left in tact. Admittedly, since the data is now referenced from another context, it would be a tricky task to continue working with it, but not totally unreasonable. Why is the original object cleared?

I'd also like to learn how this whole process takes place under the hood, if anyone has some valuable insight there.

coder34
  • 403
  • 5
  • 16
  • Because that's the whole point of *transferring* it instead of *sharing* it: not making it possible to continue to work with it, so (you can be sure that) you *don't have to deal with the trickiness* of threadsafety. – Bergi Oct 26 '17 at 22:39
  • Thank you, @Bergi. Do you know if this design decision is debated in the JS community? Or is transferring back and forth generally accepted as the most elegant and best overall solution? – coder34 Oct 26 '17 at 23:10
  • 1
    I don't see what's wrong with that solution and why you would design it differently - if you did, it wouldn't be called "transferable object" any more. If you *want* to continue working with the data, and are able to deal with the trickiness, [there's shared memory as well](http://2ality.com/2017/01/shared-array-buffer.html). You just choose what you need. – Bergi Oct 26 '17 at 23:16

1 Answers1

-1

One possible reason to transfer an object would be to reduce the amount of memory used for storing multiple copies of the same object.

2.7.2 Transferable objects

Transferable objects support being transferred across event loops. Transferring is effectively recreating the object while sharing a reference to the underlying data and then detaching the object being transferred. This is useful to transfer ownership of expensive resources. Not all objects are transferable objects and not all aspects of objects that are transferable objects are necessarily preserved when transferred.

Note: Transferring is an irreversible and non-idempotent operation. Once an object has been transferred, it cannot be transferred, or indeed used, again.

Platform objects can be transferable objects if they implement only interfaces decorated with the [Transferable] IDL extended attribute. Such interfaces must also define the following algorithms:

transfer steps, taking a platform object value and a Record dataHolder

A set of steps that transfers the data in value into fields of dataHolder. The resulting data held in dataHolder must be independent of any JavaScript Realm.

These steps may throw an exception if transferral is not possible.

transfer-receiving steps, taking a Record dataHolder and a platform object value

A set of steps that receives the data in dataHolder, using it to set up value as appropriate. value will be a newly-created instance of the platform object type in question, with none of its internal data set up; setting that up is the job of these steps.

These steps may throw an exception if it is not possible to receive the transfer.

It is up to the definition of individual platform objects to determine what data is transferred by these steps. Typically the steps are very symmetric.

See also 2.9.2. Transferable objects

guest271314
  • 1
  • 15
  • 104
  • 177