[Webkit-unassigned] [Bug 65209] Make MessagePort Transferable.

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=65209





--- Comment #7 from Kenneth Russell <kbr at google.com>  2011-08-01 15:49:09 PST ---
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > (From update of attachment 102407 [details] [details] [details])
> > > View in context: https://bugs.webkit.org/attachment.cgi?id=102407&action=review
> > > 
> > > I am still concerned that this API is badly thought out.  It seems very complex for very little gain, and generally seems to be a solution for a problem that has not yet been demonstrated to occur in the real world.
> > 
> > Which api? The js api or the C++ one.
> > 
> > The js api has been discussed a lot here: http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0304.html
> > 
> 
> The DOM API.  My problem is it seems to have added a new and exciting form of message passing, and its API conflicts with the existing API as well (you have an array parameters that can seemingly be either an array of transferable values, and array of message ports to send the message to, or an arbitrary combination of the two)

The new semantics do not conflict at all with the existing API. They were carefully designed as a generalization of the existing support for transferring MessagePort objects, and are completely backward compatible.

There is a very long discussion on public-webapps about the new functionality -- see http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/thread.html and search for "What changes to Web Messaging spec are proposed". It took quite some time, but all of the parties on the thread (including, among others, representatives from Mozilla, Microsoft, and Google) are in support of the new semantics.

There are many use cases in the area of web workers where the transfer of ownership semantics are desired -- essentially any computation that one wants to farm out to workers and which produces a lot of data. In the subdomain of 3D graphics applications, there are already WebGL apps and libraries which would immediately benefit from the new Transferable support in conjunction with typed arrays.

> 
> > As far as usefulness, one potential example is in web gl implementations which may create 1m ArrayBuffers in workers and send them to the Document for rendering. Here's a demo https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/sdk/demos/google/nvidia-vertex-buffer-object/index.html While this isn't a real world example, it is something which is representative of a the types of things real world apps of this sort would like to do.
> 
> On the other hand use cases that people have come up with in the past (drawing on a worker thread to avoid blocking the main thread) were thrown out because they added complexity, and there weren't obvious signs of people wanting the ability prior to that.
> 
> I think at minimum any implementation of this API should be prefixed.

This will be difficult. In this spec change, the semantics of postMessage were updated; a new API wasn't added.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.