Re: Data Channel Buffer Management Proposal

Yes, I agree with Randell and Harald.

On Tue, May 19, 2015 at 4:19 AM, Harald Alvestrand <harald@alvestrand.no>
wrote:

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