9 ms·

Please, no. Shared-by-default heap memory is one of the greatest mistakes ever made in language design. We need a better design justification than it's the easi

• imtringued 9y ago
  The justification is that when you have an array of 100000 elements and split it into into isolated chunks that can be processed without any synchronisation and then marshall it into json and then actually do the computation and then marshall the result into a json string and marshall it back into a javascript array is very wasteful. Heck even when I'm passing immutable messages I'd still implement it via shared memory to avoid the wasteful marshalling step.
  • spankalee 9y ago
    Fork/join on arrays and trees would be an easier to manage model, IMO.
    • pizlonator 9y ago
      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.
  • Klathmon 9y ago
    Transferrable objects fit the bill for that perfectly. They are a 0-copy way to transfer data (currently only typed arrays are supported i believe) to and from web workers without the overhead of serialization. No need for the mess that is (in my opinion) true shared memory.
• zzzcpan 9y ago
  Sadly, most people involved in language design don't actually do any serious concurrent programming and don't know any better, so the mistake keeps spreading and people keep glorifying the mess of shared-memory multithreading.
• seanwilson 9y ago
  I agree strongly with this. Multithreaded code is super hard to understand and super error-prone when you're dealing with threads and locks yourself.