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

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

--- Comment #29 from Allen Wirfs-Brock <allen@wirfs-brock.com> ---
(In reply to Domenic Denicola from comment #26)
> The question is, could interop survive with the undefined behavior Allen
> suggests? I am not so sure.

I'm concerned about that, too, which is why we go to such effort to specify
everything in such detail in the ES spec. However, I do think we are already
allowing some non-determinism into the specifications as soon as we have any
async behavior. It may be the case we are talking about falls under that
shadow.

But perhaps there is another way to specify this case deterministically that
doesn't require copying.

The specific problem that has been described here is the possibility that a
caller might change the content of the data buffer after the promise returning
call but before any actual processing of the buffer contents. If it isn't
specified at what point the buffer content is used by an asynchronous callee
the result is not deterministically specified.  Copying before returning the
promise is the proposed way to make things deterministic. It moves data access
to the earliest possible time.  The alternative would be to move the data
access until after the caller had its opportunities to modify the buffer.  This
might be done by specify that the promise returning function only captures its
raw argument values (the object references, no copying) before immediately
returning the promising.  In addition, the specification of the function would
say that all processing of the argument data is deferred until after the
current turn completes. This could be implemented by the promising-returning
function scheduling a microtask to do the actual work.

This seems consistent with the ES concurrency model where there are no data
race conditions within a turn, but where anything could happen between turns.

This is not a perfect solution (what if the buffer is modified in a subsequent
turn?); but copying everything everytime isn't a perfect solution either.

> 
> I am wary of the performance perils of excessive copying as well, but I
> don't think undefined behavior can survive long on the web.
> 
> Furthermore, it's worth pointing out that if browsers would get around to
> implementing copy-on-write for array buffers, then the copying behavior
> would be free in the usual case 

Copy-on-write is only practical for primitives things like ArrayBuffers.  It
doesn't address the general problem that arises when sharing complex object
graphs among async tasks.

Presumably, if we are talking about  WebIDL level support we will have
situations where we are dealing with object graphs and not just buffers.

Which means it's time for my annual mention of
http://www.wirfs-brock.com/allen/posts/379 . Which Web APIs need to be treated
as OS-like stable, reliable, kernel interfaces; and, which can be treated as
unreliable, evolvable, framework interfaces. There is where some platform
architecture thinking would be helpful.

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

Received on Wednesday, 18 June 2014 16:32:53 UTC