Implications for IDL

[annevk]

It seems IDL would need some updates to account for these new types.

The memory model design question also becomes important for platform APIs that might take a GrowableSharedArrayBuffer (or a view on one). I assume that's something we want to support as others it would not help Wasm a whole lot, right?

[syg]

The memory model design question also becomes important for platform APIs that might take a GrowableSharedArrayBuffer (or a view on one).

Agreed; the grows themselves can race, as well as concurrent access on the .length. Do you think WebIDL needs to say anything extra about the memory model? If .grow() and .length are specified in ecma262 with the memory model details worked out, does IDL need anything more?

I assume that's something we want to support as others it would not help Wasm a whole lot, right?

It does help wasm, in that currently, precisely because SharedArrayBuffers can't detach, the .buffer from a WebAssembly.Memory that's shared stays the same size. You can't get to the newly grown memory from the JS sides, is my understanding. See WebAssembly/design#1271.

[annevk]

IDL needs the new types (otherwise it would be hard to update WebAssembly.Memory for instance; though not in implementations as they do not use IDL for that currently I believe), I hope it can rely on ecma262 for the memory model, but it's a bit muddy with Wasm I suppose (unless that also defers to ecma262).

[bathos]

I’m guessing an [AllowResizable] extended attribute like [AllowShared] would be needed, or at least something that would similarly allow expressing this as a constraint or allowance “over” buffer source types. Most affected APIs take the BufferSource or ArrayBufferView unions or a specific TypedArray type rather than ArrayBuffer.

In many cases where these values are accepted, resizable sources should work fine because a copy of the data is made up front. But this isn’t always the case and where it isn’t there is sometimes reliance on the current immutability of byte lengths. For example, when the ImageData constructor is called with a Uint8ClampedArray, the typed array and its backing ArrayBuffer remain available for manipulation, but the byteLength is required to be divisible by four and the image’s width. The size check is performed during construction and other algrorithms are currently implicitly relying on it remaining static.

In operations that don’t copy up-front, reliance on invariant byte lengths could be subtle and might occur in both/either spec text and realized implementation code, so explicit opt-in seems safer than explicit opt-out, but this is just a guess.

[codehag]

I think we want to see this resolved, either before or conditionally for stage 3

[syg]

I’m guessing an [AllowResizable] extended attribute like [AllowShared] would be needed, or at least something that would similarly allow expressing this as a constraint or allowance “over” buffer source types.

This makes sense to me, and composes sensibly with [AllowShared].

• [AllowResizable] by itself means resizable ArrayBuffer allowed
• [AllowResizable] + [AllowShared] means growable SharedArrayBuffer allowed
• Neither means fixed-length ArrayBuffers only

I'll write up a WebIDL PR.

[syg]

I think we want to see this resolved, either before or conditionally for stage 3

Opened whatwg/webidl#982, hopefully can get reviewed before/around the next meeting.

[syg]

IDL support is now merged.