This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29388 - Attribute to prevent calls to function passing TypedArray w/ backing SharedArrayBuffer
Summary: Attribute to prevent calls to function passing TypedArray w/ backing SharedAr...
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: All All
: P2 enhancement
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
Depends on:
Reported: 2016-01-21 23:10 UTC by binji
Modified: 2019-02-28 13:34 UTC (History)
8 users (show)

See Also:


Description binji 2016-01-21 23:10:10 UTC
SharedArrayBuffers are a new spec that is being proposed for JavaScript. See the spec here:

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 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?
Comment 1 Boris Zbarsky 2016-01-22 05:20:37 UTC
Lars, how does this sound?
Comment 2 Domenic Denicola 2016-01-22 07:14:54 UTC
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).
Comment 3 Anne 2016-01-22 08:08:06 UTC
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.
Comment 4 Lars T Hansen 2016-01-22 08:57:43 UTC
I'm for it, a similar solution was suggested at Mozilla, see

Also a big +1 to Domenic's remark about increasing the precision level when shared memory might be involved, of course.
Comment 5 Lars T Hansen 2016-01-22 10:04:52 UTC
Also related discussion here:
Comment 6 Boris Zbarsky 2016-11-23 20:24:03 UTC
I would argue this should be handled via new types, not extended attributes.  See and following comments.
Comment 7 Ms2ger 2019-02-28 13:34:37 UTC
This was fixed in