W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2012

RE: Transport change in MS Proposal

From: Li Li <Li.NJ.Li@huawei.com>
Date: Fri, 31 Aug 2012 16:05:08 +0000
To: Martin Thomson <martin.thomson@gmail.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <B60F8F444AAC9C49A9EF0D12D05E0942216C0D78@szxeml535-mbx.china.huawei.com>

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? 


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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:32 UTC