Note that ImageData is cloned/copied when sent via postMessage(). So you end up with a copy of the ImageData, obviating the need for locks. I think (per my private mail to Darin which I'm restating here) that the use case is doing some kind of raytracing or something in a Worker, posting the result to a page, then blitting the result back to the canvas via putImageData().
-atw On Fri, Sep 11, 2009 at 10:54 AM, Darin Fisher <da...@google.com> wrote: > On Thu, Sep 10, 2009 at 5:21 PM, Maciej Stachowiak <m...@apple.com> wrote: > >> >> On Sep 10, 2009, at 3:12 PM, Chris Campbell wrote: >> >> Hi All, >>> >>> I had it in mind to implement support for passing data structures >>> through postMessage() using the "structured clone" algorithm laid out >>> in the HTML5 spec: >>> >>> http://dev.w3.org/html5/spec/Overview.html#posting-messages >>> >>> http://dev.w3.org/html5/spec/Overview.html#safe-passing-of-structured-data >>> >>> I've had some brief discussion with Dave Levin and Drew Wilson on >>> #chromium IRC about this, and have an approach in mind that follows >>> and elaborates on their suggestions, but there are still some holes in >>> it and I'd very much like input from people familiar with this area. >>> >>> Currently, there are several postMessage() handlers (in >>> MessagePort.idl, DOMWindow.idl, DedicatedWorkerContext.idl, and >>> Worker.idl), and they all take a DOMString for the message parameter. >>> >>> The general idea is to change that message parameter from a DOMString >>> to a new AttributeIterator type that allows walking of any sort of JS >>> structure/type. AttributeIterator would essentially be an adapter to >>> translate native V8 or JSC JavaScript objects to an agnostic interface >>> suitable for walking the structure and serializing it. I'm thinking >>> it would look something like this: >>> >>> interface AttributeIterator { >>> bool isUndefined(); >>> bool isNull(); >>> bool isFalse(); >>> bool isTrue(); >>> bool isNumber(); >>> String getNumber(); >>> bool isString(); >>> >>> // ... cover the other types including Date, RegExp, ImageData, >>> // File, FileData, and FileList ... >>> >>> // Retrieve the key for the next property (for Objects and Arrays) >>> String nextEnumerableProperty(); >>> >>> AttributeIterator getPropertyValue(key); >>> } >>> >> >> Some thoughts off the cuff: >> >> I think it would be better to write custom code for doing the cloning for >> each JS engine. For one thing, turning everything into a string is not >> necessarily the most efficient way to do things. It might be possible to >> clone the object graph more directly in a threadsafe way. Also, things like >> File and ImageData fundamentally can't be turned into a string (well >> ImageData can) >> > > What does it mean to send a File along? Isn't that just a reference to a > file? A handle of sorts. It seems like that is something that can be > passed between threads easily enough. > > What is the use case for sending ImageData? It seems like it could be to > allow a worker to modify the pixels of a canvas or it could be to share a > separate copy of the data (copy-on-write). It may be undesirable to make > the canvas have to support having its data be modified by a background > thread / background process. > > -Darin > > > >> >> Second, to be really agnostic about it, postMessage should take a generic >> Message object that has some methods that can be used to do the cross-thread >> clone without building in the assumption that it serializes to a string in >> the middle. >> >> Third, using a stateful iterator for this instead of an interface >> representing a value is not a great design. Iterators are not good when what >> you are traversing is in general a graph. >> >> Fourth, this doesn't give a way to detect if an object graph is not in >> fact legal to clone. >> >> It's kind of a shame that we have the baggage of multiple JavaScript >> engines to contend with. Trying to do things in a generic way will make this >> task needlessly more difficult. >> >> You may also want to get input on this from Oliver Hunt, who wrote the JSC >> JSON parse/stringify code; from past discussions I know has opinions on how >> cross-thread cloning should work. >> >> >> >>> >>> I'm also thinking that depending on compile-time flags, the >>> contstructor for AttributeIterator would either take a >>> v8::Handle<v8::Value> or JSC::JSvalue value. >>> >>> Then in each implementation of postMessage() the AttributeIterator >>> instance could be passed to the structured clone serializer, which >>> would return a string. Thereafter, no changes would be required to >>> WebCore internals since they already pass strings around... until on >>> the receiving end we get to MessageEvent.data where we would do the >>> deserialization in a custom getter. >>> >>> >>> Open questions: >>> >>> (1) Is passing an AttributeIterator type into postMessage() really the >>> best way to go? Drew mentioned that this might incur a bunch of ObjC >>> binding work on the JSC side... >>> >>> (2) Where should AttributeIterator live in the source tree? >>> >>> (3) Where should the serialization and deserialization routines live >>> in the source tree? >>> >>> (3) I haven't addressed the specifics of the serialized string format. >>> Plain JSON is not quite sufficient since it doesn't retain type >>> information for Date, RegExp, etc.. However, I'm not too worried >>> about coming up with a suitable format for this. >>> >>> >>> Comments, advice, admonitions welcome! :) >>> >> >> In general I'm not sure this approach is workable. At the very least File, >> FileData, FileList and ImageData need to be passed as something other than >> strings. And I think the value of making the object graph traversal code >> generic while everything else is JS-engine-specific is pretty low. In >> addition, I do not think the proposed interface is adequate to implement the >> cloning algorithm. >> >> Regards, >> Maciej >> >> >> >> _______________________________________________ >> webkit-dev mailing list >> webkit-dev@lists.webkit.org >> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > > > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
