On Thu, Jan 14, 2016 at 2:49 PM, Thomas Zimmermann <tzimmerm...@mozilla.com> wrote:
> Hi, > > I saw the lightning talk you gave in Orlando in this topic. I was > wondering if you considered implementing Transactional Memory for > SharedArrayBuffer. I have not (or, not in earnest). > JS seems like the perfect environment for TM. Are > there reasons for 'only' providing atomic ops? Just asking out of > curiosity... > The use cases that drive this work are access to multicore performance from JS as well as asm.js as a compilation target for conventional multithreaded C++; actually the asm.js case is the more important one at this time. Hence the focus for this first version of the spec has been on (very) low level mechanisms that can serve those use cases in straightforward ways. Personally I'd like to see us add additional higher-level mechanisms that are a better fit for straight JS programming. I'm hoping that we can use the current low level mechanisms to prototype higher level ones, and eventually standardize some of them. I don't know how well we can prototype TM like that - but it's early days still. --lars > Best regards > Thomas > > > Am 14.01.2016 um 14:16 schrieb Lars Hansen: > > Until now the new SharedArrayBuffer constructor and the new Atomics > global > > object [1] have been enabled on Nightly only. Starting with Firefox 46, > > those bindings will still be enabled by default on Nightly but they will > > also be available on Aurora, DevEd, Beta, and Release by flipping the > value > > of javascript.options.shared_memory to true in about:config. > > > > --lars > > > > [1] http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.html > > _______________________________________________ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
