- From: Glenn Maynard <glenn@zewt.org>
- Date: Sun, 16 Jan 2011 21:06:16 -0500
On Fri, Jan 14, 2011 at 9:10 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> We might need some ES spec changes/additions to produce methods that would
> be safe to pass. I agree that it's not that feasible for now.
Sorry, I've lost track of this part of the discussion. Is functions cloning
needed for non-copying messages, or is this tangental?
My impression for zero-copy messaging was to define it as closely to regular
messaging as possible: visible behavior almost identical to structured
clone, except for the side-effect of disabling the object after the
postMessage call completes and some special handling if multiple objects
receive the message.
Transferring an object would look something like:
port.postMessage({msg: "results", imageData:
transferObject(this.imageData)});
where transferObject returns a simple container, marking its referenced
object for transfer rather than cloning. The internal structured cloning
algorithm would then have a new step for TransferObject, causing the object
it references to be transferred, disabling the object's interface in the
calling thread, and throwing an exception if the object doesn't support
transfers.
This allows adding transfer support to new APIs later on without breaking
backwards-compatibility (ArrayBuffer and typed arrays are obvious
candidates), and avoids adding new messaging entry points.
Object recursion could be a practical problem. For example, if
transferObject(imageData) implies that imageData.data--the CanvasPixelData,
the object that we actually care about--is also transfered, does that imply
that anything else hanging off the ImageData is to be transferred? That
would land back at the future-backwards-compatibility problem, among other
things. Maybe a boolean "transferOnMessage" attribute on the specific
object to be transferred makes more sense.
--
Glenn Maynard
Received on Sunday, 16 January 2011 18:06:16 UTC