Re: Races - how bad?

On Jul 31, 2013, at 6:02 PM, Ehsan Akhgari <ehsan.akhgari@gmail.com> wrote:
> Under all proposals, there are opportunities for the main thread to at least attempt the modification of objects that could be in active use by the audio thread.
> 
> How do you mean?

I'll restrict myself to the AudioBuffer case here for brevity's sake.

In Jer's proposal, application code could attempt to call AudioBufferChannel.set() after an associated AudioBufferSourceNode has started playing and become live (see Jer's definition of "live"). The change in AudioBufferSourceNode state is effected on the audio thread per its scheduled start time, so IIRC the state change's relationship to main thread execution is unpredictable. The set() might or might not throw in a given "risky" application, depending on timing variations.

On a more careful reading of ROC's proposal, I have to say, I'm now a little less clear on the timing sensitivity since his "acquires the contents" operation occurs on assignment to AudioBufferSourceNode.buffer, which occurs in the main thread and is not timing-dependent. So perhaps ROC's proposal isn't subject to this issue.

> -- With the alternative proposals (e.g. ROC, Jer, Chris W), risky behavior may unexpectedly throw an exception due to accessing a neutered data structure or [Jer] by modifying an active buffer channel.
> 
> I don't believe that is accurate.  With these proposals, the risky behavior will unconditionally throw an exception.  Which is a definite advantage over a non-detectable runtime error that you may or may not hit when you're testing your application.

See my note re: Jer's proposal above. Due to the dependence on AudioBufferSourceNode "liveness", the behavior appears to be conditional/unpredictable.

If a proposal can guarantee runtime errors to be thrown by risky behavior, I think this is a big plus.


>  
> Runtime errors *may* signal the developer that this has taken place, if the exception is caught. In that case they may cause the end user to become aware of an application problem even if the developer never saw it. But if the errors are uncaught by the developer, the end user's likely perception is the same as above: degraded, glitchy or absent audio output.
> 
> These exceptions not being handled is basically as bad as any other unhandled exception in the web platform, and the results may vary from breakages that are not evident to the end user to complete malfunctioning of the system, depending on what code the exception skips when it's raised.

Certainly true. But IMHO a developer who tries to modify live buffer data with the expectation of getting predictable output is perhaps not going to be catching exceptions very diligently.

.            .       .    .  . ...Joe

Joe Berkovitz
President

Noteflight LLC
Boston, Mass.
phone: +1 978 314 6271
www.noteflight.com
"Your music, everywhere"