Re: Proposal for fixing race conditions

Robert O'Callahan wrote:

> The status quo in Webkit, as I understand it, allows changes to the array
> after the setValueCurveAtTime call to affect the AudioParam's behavior on
> the audio thread, so those changes may or may not be observed depending on
> all sorts of implementation details, including details of the memory
> subsystem of the underlying hardware. This is unprecedented in existing
> specs and I will object to it all the way through the W3C process if
> necessary.

Dave Herman wrote:

> I would like to back Robert up and voice my objections to the racy API.
> We should not be adding low-level data races to JavaScript or the web
> platform, nor should we be exposing architecture-specific memory models.


I could not agree more. This seemingly small step of memory data races is
the camel's nose of shared state concurrency (aka shared memory
mutithreading). One of the best things about the web platform as compared
to many other computational platforms is that it has not (yet) made the
shared-state concurrency mistake. There are many costs and benefits for
supporting shared state concurrency, and many costs and benefits for
avoiding it and achieving both concurrency and parallelism by other means.
For better or worse -- I think better -- we've paid the latter costs and
are achieving the latter benefits. This sets us on a path. To introduce
share state concurrency now would be to pay both costs and to lose many of
the benefits.

See also https://brendaneich.com/2007/02/threads-suck/

I also agree with Robert that "I will object to it all the way through the
W3C process if necessary". This one is really important.


--
    Cheers,
    --MarkM