[Bug 23369] Provide hooks for Typed Arrays (ArrayBuffer and friends)

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369

--- Comment #17 from Allen Wirfs-Brock <allen@wirfs-brock.com> ---
(In reply to Ryan Sleevi from comment #13)
> Another reason to place this in WebIDL: Currently, when dealing with
> Promise-returning specifications, it's ambiguous about how
> ArrayBuffer/ArrayBufferView data is handled.
> 
> That is, the naive approach - "Return a Promise and continuing executing
> these steps asynchronously" (as recommended by
> https://github.com/w3ctag/promises-guide ) doesn't quite work, because it
> allows the script environment to manipulate the underlying bytes while the
> Promise-d operation continues.

There is nothing unique to binary data in this regard, the same would be true
if you were passing a tree of ordinary JS objects. Also, there is nothing
unique to Promises in this regard. JS does not provide any sort of isolation
between JS-level micro-tasks or callbacks.

The solution in any specific case is simply, if you don't want anybody other
than a 'then' onFulfilled function to have access to the promise's ultimate
value don't pass the value to anybody else.  If the value is already shared,
copy it before fulfilling the promise, so any sort of deferred communications
presents the possibility of this sort of interference.  

> 
> Both WebCrypto and WebAudio have had to define how to do this, and in
> slightly different ways. WebAudio pursued an (invalid) approach of
> 'temporarily neuter', while WebCrypto pursued a path of 'copy'. Other paths
> discussed in WebCrypto were 'permanently neuter' (aka, Transferrable) or
> 'copy on write' (ruled out by implementors as complexity/performance
> overhead for the common case of ArrayBuffers)
> 
> It's unclear whether or not WebIDL should have annotations to support this
> special-case, or whether all specs should pursue one or the other. I would
> expect that, since ArrayBufferViews are seen as valid inputs, a 'copy'
> approach is desirable for consistency, but I can see specs needing to
> annotate transferrable.

These seem like everyday async cases that anybody who is designing async
subsystems have to deal with, regardless of whether or not an ArrayBuffer is
involved.  A solution that only worked with ArrayBuffer based data structures
does not help with the general problem.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Tuesday, 17 June 2014 17:07:28 UTC