[whatwg] Flow Control on Websockets

[Takeshi Yoshino]

On Fri, Oct 18, 2013 at 10:36 AM, William Chan (陈智昌)
<willchan at chromium.org>wrote:

> > Your second question is whether it's possible to stop the browser
> > reading from the socket. Yes, just don't return from your onmessage
> > handler until you've actually finished handling the message. If you
> > fire up a new worker then tell the browser you're done, you're seeing
> > the inevitable result of that. You have to wait on the worker - or, if
> > you want to process say four messages in parallel, wait on the worker
> > pool until it's dropped below four active before returning.
> >
>
> Pardon the ignorance, but doesn't the onmessage handler run on the main
> thread? If you don't return from it, then doesn't that block the main
> thread? If so, then I think that's a bad solution. Blocking the main thread
> is generally terrible IMO and should be avoided.
>
>
If an app is designed so that main JS thread does actual work (yes, this is
basically bad choice as Willchan said), we could choose to make back
pressure based on buffer consumption (onmessage processing) rate.

If an app is designed to be responsive and such work is done by some other
asynchronous HTML5 API, this method doesn't work.

If such blocking work is done in a worker, this method should work. (FYI,
Chrome (Blink) doesn't have such flow control between network thread and
worker thread yet, so this shouldn't work on Chrome for now).