Further workaround to try to push node.js event loop forward

[scottnonnenberg]

We're still having problems with the Node.js websocket in Electron, tracked here: #1075

This takes our workaround and amps it up. Instead of calling setImmediate after making a web request, we do it every second. I'm hoping that this extreme approach solves the problem, and then we can do the work to pare back as necessary.

[liliakai]

This certainly seems extreme. I don't really understand how the node event loop is integrated in the browser window process well enough to understand how it could be blocked and why this strategy might help. Should this behavior be limited to linux?

Do we think this is related to process throttling that occurs when the window is in the background? If so, maybe we can try disabling that in webPreferences.

[scottnonnenberg]

It should have very, very little overhead, so I don't think it needs to limited to Linux.

Now, as far as the why... my mental model is that sometimes things get stuck on the Node.js side. That simple repro of two quick web requests proves it, and also shows that a little push from us can help. Our first workaround's single setImmediate call after every web request helps, but with a long-lived network connection like a websocket, perhaps it needs more frequent pushes? Not only that, but a slower internet connection may take longer than one second to respond, and in that case our workaround fired too early.