As a result of some conversations on IRC, it came to light that a bunch of blocking IO operations were apparently moved off of MainThread (presumably to avoid UI 'jank'), and instead Dispatched to STREAMTRANSPORTSERVICE (aka STS thread).
Some examples pointed out to me: FilePicker, the spell-checker, the DeviceStorage DOM code, DOM cache code in Manager.cpp (via BodyStartWriteStream()), even perhaps ResolvedCallback in ServiceWorkers. (I haven't looked closely at all of the uses yet.) Good, right? No jank in the UI! No - now the jank is in the network code! STS is the primary network thread, and blocking that without a Darn Good Reason will cause all sorts of negative effects. Page loads, XHR, WebSockets, WebRTC (which will react by adding delay to cover the 'jitter' in apparent network RTT) and many other things will have small-to-large negative impacts. Perhaps some of these listed above (and others) don't block or even have a legitimate need to run on STS thread - ok, if so, comment as to why it's ok/needed. Everyone else should not be using STS thread as a convenient target.... It does point out that with the need to get a lot of blocking operations off of MainThread, it would help other modules to have a single service or ThreadPool for dumping such operations to. This would mean less code, less incorrect/undone thread shutdowns/etc. Thoughts? (Perhaps such a service could use LazyIdleThreads, which will shut themselves down after inactivity.) -- Randell Jesup, Mozilla Corp remove "news" for personal email _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
