29388 2016-01-21 23:10:10 +0000 Attribute to prevent calls to function passing TypedArray w/ backing SharedArrayBuffer 2019-02-28 13:34:37 +0000 1 1 1 Unclassified WebAppsWG WebIDL unspecified All All RESOLVED FIXED P2 enhancement --- 1 binji cam annevk bzbarsky d jfb lhansen mike Ms2ger public-script-coord public-webapps-bugzilla oldest_to_newest 124661 0 binji 2016-01-21 23:10:10 +0000 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? 124663 1 bzbarsky 2016-01-22 05:20:37 +0000 Lars, how does this sound? 124665 2 d 2016-01-22 07:14:54 +0000 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). 124666 3 annevk 2016-01-22 08:08:06 +0000 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. 124667 4 lhansen 2016-01-22 08:57:43 +0000 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. 124669 5 lhansen 2016-01-22 10:04:52 +0000 Also related discussion here: https://github.com/lars-t-hansen/ecmascript_sharedmem/issues/38 128252 6 bzbarsky 2016-11-23 20:24:03 +0000 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. 129580 7 Ms2ger 2019-02-28 13:34:37 +0000 This was fixed in https://github.com/heycam/webidl/pull/353.