- From: Venkatesan, Ganesh <ganesh.venkatesan@intel.com>
- Date: Fri, 31 Aug 2012 21:13:48 +0000
- To: Li Li <Li.NJ.Li@huawei.com>, Martin Thomson <martin.thomson@gmail.com>
- CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
> 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? I get your point about unbounded delays due to the processing of events queued up in a "queue". However, I am not sure how the delay computed to be 50ms? It is 60ms (t+70ms - (t+10ms)). Am I missing something? Cheers -- ganesh -----Original Message----- From: Li Li [mailto:Li.NJ.Li@huawei.com] Sent: Friday, August 31, 2012 9:05 AM To: Martin Thomson Cc: public-webrtc@w3.org Subject: 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 21:14:18 UTC