Re: Proposal for fixing race conditions

On Thu, Jul 4, 2013 at 12:14 PM, Chris Rogers <crogers@google.com> wrote:

> For any practical and real-world use cases using the API, there aren't
> really any problems any more than already exist today with raciness of
> asynchronous callbacks/event-handlers.  We already live in a world where
> XHR completions, setInterval/setTimeout, requestAnimationFrame, file/blob
> async requests, receiving responses from web workers, events from
> HTMLMediaElement, and many others can all occur in unpredictable orders and
> at unpredictable times.  Even something like rendering the contents of a
> video stream from <video> into a canvas and then reading the pixels back is
> going to involve lots of raciness in terms of exactly what frame you're
> reading at any given time.
>

The nondeterminism arising from those APIs is limited in carefully
specified ways. For example, when drawing a <video> into a canvas, the
frame may be chosen nondeterministically, but you never get half of one
frame and half of the next, or whatever else happens to be in the
framebuffer while you're reading it. Likewise, the ordering of HTML5 task
dispatch is nondeterministic, but also carefully constrained. In
particular, each task executes as an atomic unit and is not interleaved
with other tasks.

We should discuss very specific real-world use cases because I think we're
> in pretty good shape here.
>

Suppose someone writes the following code:
  var audioBuffer =
audioContext.createBuffer(1,10000,audioContext.sampleRate);
  var audioBufferSourceNode = audioContext.createBufferSource();
  audioBufferSourceNode.start(audioContext.currentTime + 0.1);
  for (var i  = 0; i < 10000; ++i) {
    audioBuffer.getChannelData(0)[i] = ...;
  }
The spec doesn't say what happens in this situation. That's probably
because with the Webkit/Blink implementation, as I understand it, almost
anything can happen. On a fast-enough machine, most of the time, the sound
will probably play as expected. On a slow machine, or if you hit a GC or a
page fault, or if the memory subsystem is particularly lazy, you could get
zeroes interspersed with the data you wanted. The unpredictability of this
code (especially given it "usually works"), is a big problem.

Now suppose we want to implement a Web browser on a multiprocessor
architecture where there is no general-purpose shared memory (only message
passing), or general-purpose shared memory is very expensive. Then it is
very difficult to implement Web Audio in a way that the above code could
ever work. (This is only barely hypothetical, since Mozilla is actually
working on a browser with this architecture.) You could say it's OK to
break such poorly-written Web applications, but browser development is all
about getting poorly written applications to work well.

Alternatively, suppose you want the Javascript engine to allow ArrayBuffer
contents to be moved by a compacting garbage collector. That is very
difficult to do while the audio thread has concurrent access to the
ArrayBuffer contents, so you'll force the JS engine to support pinning,
which is a real pain.

Against issues like these, the arguments for freely-shared memory seem very
weak to me. "So that Webkit/Blink can keep running legacy demos with
slightly higher performance and a lower-complexity implementation", as far
as I can tell.

Perhaps, because these are hypothetical situations, you feel they aren't
"real-world use cases" and therefore don't matter. But unfortunately we do
have to design Web APIs with an eye to the future. Saying "this design
isn't currently causing me any pain, so let's lock it in for eternity" has
caused vast problems on the Web.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w  *
*