RE: Transport change in MS Proposal

Martin,

My concern is on whether the Javascript callbacks can be executed in timely fashion. Based on this analysis [1], it seems a callback is queued like timer events.
For a contrived example, in a JS thread:

At t: register a callback to listen on bandwidth change;

At t+10ms: the callback fires, but is queued as the thread is executing another function;

At t+70ms: the function finishes and the callback is executed;

So there is a 50ms delay. Would such unbound delay cause any problem in practice or do we have to force the use of worker threads? 

Thanks,
Li

[1] http://blogs.msdn.com/b/davrous/archive/2011/07/15/introduction-to-the-html5-web-workers-the-javascript-multithreading-approach.aspx


-----Original Message-----
From: Martin Thomson [mailto:martin.thomson@gmail.com] 
Sent: Wednesday, August 29, 2012 5:36 PM
To: Li Li
Cc: public-webrtc@w3.org
Subject: Re: Transport change in MS Proposal

On 29 August 2012 12:35, Li Li <Li.NJ.Li@huawei.com> wrote:
> Martin,
>
> In the MS proposal [1], a JS application has the ability to change the transport for a RealtimeMediaStream object, when detecting the transport bandwidth is too low through JS callback.
> Since JS execution cannot be interrupted by callbacks, what happens if the callback is delayed by a long running JS block?

Javascript should not block in this way.  If your javascript does not
return control to the browser at least 60 times a second, people are
going to notice some performance degradation.  Even assuming that you
are operating slower than this, I'm not sure what you imagine would be
so time-sensitive as to require this sort of reaction time.

--Martin

Received on Friday, 31 August 2012 16:07:59 UTC