On Fri, Jan 14, 2011 at 9:10 AM, Boris Zbarsky <bzbar...@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