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

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

--- Comment #18 from Ryan Sleevi <sleevi@google.com> ---
(In reply to Allen Wirfs-Brock from comment #17)
> 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.

This isn't actually correct.

The WebIDL specification defines the conversion routines for ECMAscript objects
into WebIDL types. This conversion process is documented as copying (eg: a
DOMString that contains the value equivalent to the ECMAScript that results
from the ToString(v))

A tree of objects is cascaded into IDL types, if using a dictionary/sequence,
for example.

The only time that I can see that WebIDL doesn't provide this explicit
conversion is the any/object types, which retain references to their underlying
platform type.

That's why this is a request to provide a WebIDL definition for how the
ECMAScript %TypedArray% type is handled, within WebIDL, rather than relying on
"object" semantics.

> 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.  

I fear you've misunderstood this bug.

This has nothing to do with the promises ultimate value (eg: the output
argument); it has everything to do with the inputs to a Promise-returning
function (eg: function arguments).

As noted, specifications that wish to perform asynchronous operations on the
binary data need to explicitly document that a copy is returned (otherwise,
once control returns to the caller, the caller can manipulate the underlying
data in parallel to the Promise-returning operation)

Not all specifications will; some may be able to perform their tasks over the
data before yielding control to the author.


> 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.

WebIDL defines how this works for most other ECMAScript primitives, by
providing IDL types that represent and duplicate the data, leading them to to
be "safe" for asynchronous operations. This is not special-casing ArrayBuffer;
this is ensuring that ArrayBuffer has a similar first-class experience.

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

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