This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
SharedArrayBuffers are a new spec that is being proposed for JavaScript. See the spec here: http://lars-t-hansen.github.io/ecmascript_sharedmem/shmem.html They use the same TypedArray hierarchy, but they will have a backing store that can be shared between Workers. It's likely that most APIs will not want to allow TypedArrays with a backing SharedArrayBuffer to be passed, and instead to throw an exception. I sent a message to blink-dev asking about this (see https://groups.google.com/a/chromium.org/d/topic/blink-dev/EsX3S43nm-0/discussion) and they suggested communicating with the WebIDL authors. My initial thought is that passing shared TypedArrays should be opt-in, so by default they will throw an exception. The APIs that want to accept a shared TypedArray will be annotated in some way (per function? per function argument?) Does this seem reasonable?
Lars, how does this sound?
Opt-in makes a lot of sense to me. It seems most natural to opt in on a per-argument basis. - ArrayBuffer -> (ArrayBuffer or SharedArrayBuffer) - Int8Array -> [AllowShared] Int8Array, etc. - ArrayBufferView -> [AllowShared] ArrayBufferView There should then be some sort of requirement that specs which opt in to this have their processing models for the typed array/array buffer argument more well defined than they are currently. Specs are generally not very precise about when or if they do copies, transfers, moves, etc. IDL tries to enforce more precision with: > At the specification prose level, IDL buffer source types are simply references to objects. To inspect or manipulate the bytes inside the buffer, specification prose MUST first either get a reference to the bytes held by the buffer source or get a copy of the bytes held by the buffer source. With a reference to the buffer source’s bytes, specification prose can get or set individual byte values using that reference. But for APIs that accept SAB I'd expect extreme precision, possibly with branching paths depending on SAB or not (e.g. "get a reference to the bytes held by the buffer source" for SAB and "get a copy of the bytes held by the buffer source" for AB).
See bug 28798 for the suggestion to use new IDL syntax to indicate whether to use by-reference or copy the input. I think we should fix that together with this bug to make things a bit simpler and more obvious.
I'm for it, a similar solution was suggested at Mozilla, see https://bugzilla.mozilla.org/show_bug.cgi?id=1231687. Also a big +1 to Domenic's remark about increasing the precision level when shared memory might be involved, of course.
Also related discussion here: https://github.com/lars-t-hansen/ecmascript_sharedmem/issues/38
I would argue this should be handled via new types, not extended attributes. See https://bugzilla.mozilla.org/show_bug.cgi?id=1231687#c11 and following comments.
This was fixed in https://github.com/heycam/webidl/pull/353.