flagxor

3 ms·

1.
by flagxor 9y ago
setTimeout is obviously a simpler primitive to understand in isolation than monitors/conditionvars, but I would argue that when used in equally complex scenarios, similar challenges emerge. Something like Dinning Philosophers is no les
2.
by flagxor 9y ago
Many factors and capabilities went into Firefox's success. While it's easy to enumerate the primitives required in hindsight, I'm doubtful that if OSes of the period had taken a restrictive stance based on contemporary ideas
3.
by flagxor 9y ago
This seems rather racy in Chrome, despite the I/O being deferred to the end :-) (function() { var x = ''; setTimeout(function() { setTimeout(function() { x += 'a'; }, 6); }, 4); setTimeout(function()
4.
by flagxor 9y ago
> Are you sure that setTimeouts are run in a non-deterministic order? Certainly, if they are issued from different callbacks. :-) And in relation to how they may happen to be interleaved with I/O. Also add to the non-determinism buc
5.
by flagxor 9y ago
Event loops have these too, they just go by different names: * non-determinism -> order in which setTimeouts run * race conditions -> callbacks happen in an unexpected order * deadlock -> broken callback chain
6.
by flagxor 9y ago
As long as we offer a similar `unsafe` option, a stronger type system around mutability+concurrency might have a range of benefits for JS. Rust's definitely has a number of virtues. A little hard to imagine grafting onto JS though. :-
7.
by flagxor 9y ago
It would have been a shame if the OSes on which Firefox runs had similarly limited access to shared memory to one particular "safe" style in the spirit of paternalistic caution. Would Rust/Servo have been possible without acc