W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2014

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

From: <bugzilla@jessica.w3.org>
Date: Tue, 17 Jun 2014 18:28:50 +0000
To: public-script-coord@w3.org
Message-ID: <bug-23369-3890-pGIkRcOcyL@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23369

--- Comment #19 from Allen Wirfs-Brock <allen@wirfs-brock.com> ---
(In reply to Ryan Sleevi from comment #18)
> (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. 
...

I'm afraid I have to continue to disagree. 

This stuff all will be  happening in the context of an standard ECMAScript
environment that includes ES based specifications of Promise, ArrayBuffer,
various typed arrays, DataView, etc. And none of the conversions and copying
you describe are normal ES behaviors. In particularly, the copying of a graph
of objects object when passed behavior you describe would be a very rare
occurrence in idiomatic ES code.

Sure, you can make your WebIDL-based APIs do whatever you want, but you should
get past the perspective that it is WebIDL that is defining the entire
programming model and the expected idioms ES programmers. ES programmers will
be using Promises for many things, and most of them won't be defined using
WebIDL interfaces and semantics.

Web platform APIs should start out as good idiomatic ES API and then get
refined, if necessary, to ensure any platform invariants. Not the other way
around.

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

I actually don't think it makes a difference.  As long as async tasks are
involved, the stability of both inputs and outputs can be an issue.  Whether or
not mutable values are accessible from other logically concurrent tasks can be
an issue in either case. But, as long as you have shared state (which you do
have even with ES's concurrency constrained event loop tasking) you have to
deal with it.)
> 
> 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)

If there are integrity issues involved, you may need to explicitly copy.  But
it many other situations such copying will be too expensive and it will be
perfectly adequate to document that the passed data structures should not be
accessed or modified by the caller until the result promise has been settled.
What if the caller violates that restriction?  It's a programmer bug just like
missions of other possible programming bugs.

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

The important thing in ES isn't the primitives, it is the new abstractions
(call them "classes" if you want) that ES programmer construct out of graphs of
ordinary ES objects. WebIDL doesn't really provide much at all that generalizes
over such ES based abstractions.

You are taking the approach that WebIDL is defining "first-class" behavior and
that makes everything else an ES programmer does "second-class".  That's just
backwards.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Received on Tuesday, 17 June 2014 18:28:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC