- From: Kenneth Russell <kbr@google.com>
- Date: Tue, 18 May 2010 14:38:21 -0700
- To: Mark Seaborn <mseaborn@google.com>
- Cc: "Mark S. Miller" <erights@google.com>, "arun@mozilla.com" <arun@mozilla.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Erik Arvidsson <erik.arvidsson@gmail.com>, "es-discuss@mozilla.org" <es-discuss@mozilla.org>
On Tue, May 18, 2010 at 2:15 PM, Mark Seaborn <mseaborn@google.com> wrote: > On Tue, May 18, 2010 at 9:52 PM, Kenneth Russell <kbr@google.com> wrote: >> On Tue, May 18, 2010 at 9:23 AM, Mark S. Miller <erights@google.com> wrote: >>> 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. > > Couldn't you provide a fast channel object that is implemented using > shared memory, but hide the fact that it is using this buffer, so that > only message-passing semantics are exposed? Possibly. There is a large API design space. The difficulty is that the current message passing semantics mandate allocation of storage on the receiving end. If the API were structured to allow the receiver of the message to read it into preexisting storage, that would address some of the problem. -Ken
Received on Tuesday, 18 May 2010 21:39:18 UTC