- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Tue, 19 May 2015 02:46:44 -0400
- To: public-webrtc@w3.org
On 5/18/2015 3:09 PM, Benjamin Schwartz wrote: > Yes, Promises only resolve once, so you would need to call this method > each time you wanted to start waiting. Promises are fast: the slowest > Promise operation I could find takes 54 microseconds in Chrome for > Android on my Nexus 4. That's a lot better than > setTimeout/setInterval, which takes at least 4000 microseconds! There are reasons "small" timers often get bumped up. And don't forget that this would be originating in a different thread than JS execution as well. However, point taken that promises are better than timer-polling! > Promise<void> waitForBufferedAmountBelow (unsigned long amount); > This method returns a Promise that resolves when this.bufferedAmount <= amount, or rejects if the channel reaches the "closed" state. There are some details about this to resolve: * Does this resolve on a transition from "> amount" to "<= amount"? Or does it fire as written (loosely) above, which implies it resolves immediately if the current state is <= amount. If the usage is roughly "check bufferedAmount after each send(), then if above upper_threshold call waitForBufferedAmountBelow(lower_threshold) and stop sending", then firing immediately makes sense. I assume this is what was intended. I'm in favor of this. -- Randell Jesup -- rjesup a t mozilla d o t com Please please please don't email randell-ietf@jesup.org! Way too much spam
Received on Tuesday, 19 May 2015 06:47:53 UTC