Re: Data Channel Buffer Management Proposal

Den 19. mai 2015 08:46, skrev Randell Jesup:
> 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.


I would think it would be the latter, otherwise you get a nasty race
condition where you wait for a promise that never fires (because you
were already <= amount due to a parallel draining process).

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

Received on Tuesday, 19 May 2015 08:19:42 UTC