- From: Kenneth Russell <kbr@google.com>
- Date: Tue, 18 May 2010 13:52:27 -0700
- To: "Mark S. Miller" <erights@google.com>
- Cc: Oliver Hunt <oliver@apple.com>, "arun@mozilla.com" <arun@mozilla.com>, "es-discuss@mozilla.org" <es-discuss@mozilla.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Erik Arvidsson <erik.arvidsson@gmail.com>
On Tue, May 18, 2010 at 9:23 AM, Mark S. Miller <erights@google.com> wrote: > On Tue, May 18, 2010 at 9:14 AM, Oliver Hunt <oliver@apple.com> wrote: >> >> On May 18, 2010, at 9:04 AM, Mark S. Miller wrote: >> >> On Tue, May 18, 2010 at 12:22 AM, Erik Corry <erik.corry@gmail.com> wrote: >>> >>> 2010/5/18 Kenneth Russell <kbr@google.com>: >>> > On Thu, May 13, 2010 at 8:28 PM, Allen Wirfs-Brock >>> > <Allen.Wirfs-Brock@microsoft.com> wrote: >>> >>> Vladimir Vukicevic vladimir@mozilla.com said: >>> > Using hypothetical native JavaScript buffer objects would be >>> > compatible with our current relatively simple use of TypedArrays. >>> > However, we have begun to explore more advanced use cases including >>> > sharing TypedArrays among web workers, and between ECMAScript and >>> > browser plugins. In these situations, if we were to use native >>> > JavaScript buffer objects, we would need to specify additional >>> > behavior for the objects. >>> >>> This looks like a can of worms to me. Shared buffers break with the >>> shared-nothing and message-passing paradigms and necessitate >>> synchronization primitives. >> >> +1. >> >> There has not been any suggestion of concurrent access to the same shared >> buffer that i am aware of (otherwise i would have called this out in the >> WebGL WG) -- the only thing that has been discussed is interaction with >> workers, where we sharing of the underlying data buffer was always couched >> in terms of copy-on-write semantics (eg. make the cloning fast by avoiding >> cloning if possible) > > Whew. Yes, copy-on-write sharing with workers is a great idea. IIUC, it > should be a completely transparent, semantics free optimization. Thanks for > clearing that up. I hesitate to mention this, but outside of the WebGL working group some colleagues and I have discussed using a combination of shared buffers and postMessage semantics to achieve direct sharing of buffers' contents. The use case is that a worker repeatedly produces new vertex data to be consumed by the main thread. Without the ability to share one or more buffers directly, the worker thread must repeatedly allocate new storage to be handed off to the main thread. If the main thread does not promptly deallocate this storage, the system will rapidly exhaust available resources. We are interested in doing some prototypes to see what works. Currently I would not like to specify any behavior in this area or artificially limit the ability to experiment. -Ken
Received on Tuesday, 18 May 2010 20:53:24 UTC