4 ms·

You can implement that on top of threads.

spankalee 9y ago
Of course you can. You can implement anything on top of threads, especially non-determinism, race conditions and deadlocks.
- 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
  - colordrops 9y ago
    Are you sure that setTimeouts are run in a non-deterministic order? Callbacks can only come back in an unexpected order if you are using I/O. A broken callback chain is not the traditional definition of "deadlock".
    - 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 bucket: the order in which messages arrive from separate Workers. > Callbacks can only come back in an unexpected order if you are using I/O. Which abounds and takes many forms both in the browser and node.js. > A broken callback chain is not the traditional definition of "deadlock". Indeed, but it is the same class of developer hazard at play: waiting for an event to happen than will never come. Admittedly, only a subset of dropped callback chains correspond to the strict definition of deadlock: those where a chain is involved in marking a state/resource as available. For example: I ignore the next button press on a ui that disables the button pending a reply because I accidentally failed to update the button state when a network request failed.
      - colordrops 9y ago
        > Certainly, if they are issued from different callbacks. :-) And in relation to how they may happen to be interleaved with I/O. That's non determinism from I/O, not from the callback or the setTimeout. setTimeouts are called in order based on schedule time. And you can't blame non-determinism in JS on I/O. No language in existence is deterministic based on that measure.
        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() { setTimeout(function() { x += 'b'; }, 5); }, 5); setTimeout(function() { console.log(x); }, 50); })(); It's a fair point that generally I/O is the source of the bulk of the non-determinism in most JS programs. But if that I/O non-determinism is present (as it is in most useful programs), event loops aren't a panacea to avoid peril from it. Concurrency introduces another source of non-determinism. But just as good programs use care with the ideally limited amount of code responding to events, good concurrent programs use similar care with access to shared state. I'm unsure if the strawman syntax proposed encourages that care, but it is interesting that it can at least be done without breaking basic safety + performance. With SharedArrayBuffer on the way, we'll get all the non-determinism of parallel execution peeping through to JS without a particularly JS friendly syntax, so it's at least worth thinking about if something should be added to JS.
        olau 9y ago
        I object to the term "similar care". There's a big difference in what it takes to understand thread issues compared to single-threaded event-based systems. For instance, if I'm not mistaken, your setTimeout thing is relying on precise timing. But this is documented when you look up setTimeout. It's not difficult to understand. How to use locks and conditions/monitors correctly IS difficult to understand. You can't just read a few lines in the API documentation and proceed on to write correct code, beyond small toy examples.
  - a-kojeve 9y ago
    Yeah, but nobody relies on the execution order of disparate callbacks to achieve their results in JS. You're going to get burned in like two seconds if you try to do anything you listed. Lower level concurrency primitives in other languages allow developers to build fragile solutions which work 99% of the time until they deadlock and everything blows up. The concurrency model in JS is very explicit about being "no guaruntees."
    - pizlonator 9y ago
      There are many reasons why complex software fails in the 1% case. Concurrency is not the only reason. In my experience it is not the top reason. Our top hard-to-repro or no-repro crashes in JavaScriptCore are from non determinism introduced by the workload itself. Inside our engine we have many sources of nondeterminism that manifests even with concurrency features disabled.

Of course you can. You can implement anything on top of threads, especially non-determinism, race conditions and deadlocks.

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
- colordrops 9y ago
  Are you sure that setTimeouts are run in a non-deterministic order? Callbacks can only come back in an unexpected order if you are using I/O. A broken callback chain is not the traditional definition of "deadlock".
  - 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 bucket: the order in which messages arrive from separate Workers. > Callbacks can only come back in an unexpected order if you are using I/O. Which abounds and takes many forms both in the browser and node.js. > A broken callback chain is not the traditional definition of "deadlock". Indeed, but it is the same class of developer hazard at play: waiting for an event to happen than will never come. Admittedly, only a subset of dropped callback chains correspond to the strict definition of deadlock: those where a chain is involved in marking a state/resource as available. For example: I ignore the next button press on a ui that disables the button pending a reply because I accidentally failed to update the button state when a network request failed.
    - colordrops 9y ago
      > Certainly, if they are issued from different callbacks. :-) And in relation to how they may happen to be interleaved with I/O. That's non determinism from I/O, not from the callback or the setTimeout. setTimeouts are called in order based on schedule time. And you can't blame non-determinism in JS on I/O. No language in existence is deterministic based on that measure.
      - 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() { setTimeout(function() { x += 'b'; }, 5); }, 5); setTimeout(function() { console.log(x); }, 50); })(); It's a fair point that generally I/O is the source of the bulk of the non-determinism in most JS programs. But if that I/O non-determinism is present (as it is in most useful programs), event loops aren't a panacea to avoid peril from it. Concurrency introduces another source of non-determinism. But just as good programs use care with the ideally limited amount of code responding to events, good concurrent programs use similar care with access to shared state. I'm unsure if the strawman syntax proposed encourages that care, but it is interesting that it can at least be done without breaking basic safety + performance. With SharedArrayBuffer on the way, we'll get all the non-determinism of parallel execution peeping through to JS without a particularly JS friendly syntax, so it's at least worth thinking about if something should be added to JS.
        olau 9y ago
        I object to the term "similar care". There's a big difference in what it takes to understand thread issues compared to single-threaded event-based systems. For instance, if I'm not mistaken, your setTimeout thing is relying on precise timing. But this is documented when you look up setTimeout. It's not difficult to understand. How to use locks and conditions/monitors correctly IS difficult to understand. You can't just read a few lines in the API documentation and proceed on to write correct code, beyond small toy examples.
- a-kojeve 9y ago
  Yeah, but nobody relies on the execution order of disparate callbacks to achieve their results in JS. You're going to get burned in like two seconds if you try to do anything you listed. Lower level concurrency primitives in other languages allow developers to build fragile solutions which work 99% of the time until they deadlock and everything blows up. The concurrency model in JS is very explicit about being "no guaruntees."
  - pizlonator 9y ago
    There are many reasons why complex software fails in the 1% case. Concurrency is not the only reason. In my experience it is not the top reason. Our top hard-to-repro or no-repro crashes in JavaScriptCore are from non determinism introduced by the workload itself. Inside our engine we have many sources of nondeterminism that manifests even with concurrency features disabled.