[email protected] <[email protected]> fyi Note that I'm currently changing the internal implementation of ArrayBuffers. This should be done soon, but please hold off landing bigger changes until then. Tracking bug here: https://code.google.com/p/v8/issues/detail?id=3996
best -jochen On Sat, Apr 18, 2015 at 3:18 AM Ben Smith <[email protected]> wrote: > Contact emails [email protected],[email protected] Spec > https://docs.google.com/document/d/1NDGA_gZJ7M7w1Bh8S0AoDyEqwDdRh4uSoTPSNn77PFk/edit?usp=sharing > Summary Adds new JavaScript types SharedArrayBuffer, > Shared{Int,Uint}{8,16,32}Array, SharedFloat{32,64}Array and > SharedUint8ClampedArray. SharedArrayBuffers can be posted to Workers and > without neutering the buffer from the sending side. To be fully useful, > additional APIs are needed for atomic reads/writes and synchronization > primitives. Motivation Workers can currently share memory by copying or > transferring ArrayBuffers. For some cases > <https://www.youtube.com/watch?v=-xNZYr40QOk>, this limitation does not > perform well enough. Shared memory allows for comparatively lightweight > synchronization between workers. > > Furthermore, the lack of shared memory prevents many C/C++ applications > from being compiled to JavaScript > <http://kripken.github.io/emscripten-site/docs/porting/guidelines/portability_guidelines.html#code-that-cannot-be-compiled>. > The current solution requires limiting the application to a single thread, > or perhaps emulating threads with an interpreter > <https://github.com/kripken/emscripten/issues/3342>. > > Finally, adding a low-level primitive like shared memory opens the door > to higher-level abstractions <https://gist.github.com/dherman/5463054> > that can be implemented in JavaScript without adding any new APIs. > > The Path to Parallel JavaScript > <https://blog.mozilla.org/javascript/2015/02/26/the-path-to-parallel-javascript/> > has more detail about the current state of parallel JavaScript and the > benefits of extending the web platform with additional parallelism > primitives. > Compatibility Risk Firefox: In development Internet Explorer: No public > signals Safari: No public signals Web developers: No signals Describe the > degree of compatibility risk you believe this change poses Firefox > already has an implementation of this > <https://bugzilla.mozilla.org/show_bug.cgi?id=933001> in Firefox nightly. > IE is moving forward with asm.js support > <http://blogs.msdn.com/b/ie/archive/2015/02/18/bringing-asm-js-to-the-chakra-javascript-engine-in-windows-10.aspx> > so they may be interested in supporting SharedArrayBuffers as well, though > there is currently no public discussion about this. > > Many people have concerns <https://news.ycombinator.com/item?id=9115231> > about adding shared memory to JavaScript. There are questions of > complexity, whether it is necessary ("isn't message passing good enough?"), > how it will interact with the JavaScript event loop and existing APIs, etc. > Some of these issues are discussed in this blog post > <https://blog.mozilla.org/javascript/2015/02/26/the-path-to-parallel-javascript/>. > Ongoing technical constraints > SharedArrayBuffers are essentially a parallel hierarchy to the currently > implemented ArrayBuffer/TypedArray types. There is a concern about how much > code should be/can be shared between the implementations. Will this > feature be supported on all six Blink platforms (Windows, Mac, Linux, > Chrome OS, Android, and Android WebView)? Yes or no. > Yes. OWP launch tracking bug None yet. Link to entry on the Chromium > Dashboard https://www.chromestatus.com/features/4570991992766464 Requesting > approval to ship? > No. > -- -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
