3 ms·
Remember when a tab freezing didn't make Firefox's UI chrome unresponsive? I do, too.
by kick 7y ago
Remember when a tab freezing didn't make Firefox's UI chrome unresponsive? I do, too.
- pessimizer 7y agoWeb 4.0 is the internet of race conditions. Thanks, javascript everywhere.
- hombre_fatal 7y agoI don't get it. Javascript would have categorically improved on this compared to more traditional multi-threaded solutions.
- GrayShade 7y agoYou can still have race conditions in single-threaded async code.
- cjones26 7y agoWell I don't think that could technically be considered a race condition, as it's clearly a design problem in the code causing what would appear to be a "pseudo" race condition.
- GrayShade 7y agoWhy not? It is a race condition, just like TOCTTOU is a race condition that doesn't necessarily involve threads. Note the difference between race conditions in general and data races that involve unsynchronized access to shared memory.
- minitech 7y agoAnd “Javascript would have categorically improved on this compared to more traditional multi-threaded solutions” remains true nevertheless.
- cjones26 7y agoWhat? JavaScript is a single threaded language...
- Yoric 7y agoAnd despite this, I've encountered lots of race conditions in JavaScript, thanks to the magic of async programming. Harder to debug than multi-threaded ones, too.
- amelius 7y agoEvery tab's UI (and the main UI) can still run in a different thread or process, I suppose ...
- skrebbel 7y agoI'd assume that the Firefox chrome runs in its own process. Why would the switch to web components for the chrome change that?
- MikusR 7y agoWhen was that?
- floatboth 7y agoI remember when it did — before the "Electrolysis" project, when everything ran in one process. This was quite a long time ago already.