5 ms·

My understanding of Javascript is that it is essentially single-threaded. Maybe I am mistaken, but if that is indeed the case, how does something like JS-CSP or

My understanding of Javascript is that it is essentially single-threaded. Maybe I am mistaken, but if that is indeed the case, how does something like JS-CSP or Clojurescript's core.async accomplish concurrency? Has there been a change in the underlying Javascript? Is it just using tricks to make single-thread act like multi-thread?

arnarbi 12y ago
Short answer: Yes. Concurrency does not necessarily mean parallelism (multi-threading). CSP-derived mechanisms provide abstractions for units-of-work to yield control to other units-of-work. Here, a unit of work is a function invocation, but it can be a block, a thread-like object etc. With such primitives it is fairly easy to build cooperative (as opposed to pre-emptive) concurrency mechanisms. For a mature example, see e.g. http://www.stackless.com/ http://www.stackless.com/
craigching 12y ago
In the JavaScript "user space" you don't have access to threads (with the exception of web workers), but the JS engines themselves are multi-threaded and fully concurrent. This is why your UI doesn't freeze when doing XHR (assuming you're not doing synchronous XHR) and represents the need for elegantly handling asynchronicity.
dminor 12y ago
Say you have: function one() { console.log("one"); setTimeout(one, 1000); } function two() { console.log("two"); setTimeout(two, 2000); } one(); two(); They are executing concurrently, but never in parallel (since javascript is single threaded). Now, how do you coordinate them if you need to? This is what CSP helps you do.
- lbradstreet 12y ago
  I've spent a fair amount of time in core.async, and I feel like I'm on the edge of enlightenment here, but I don't quite understand how CSP helps with this example. Is the point that you can take multiple puts off the channel in one go? That's the only thing I can think of. Maybe you could present the CSP alternative, and a basic example use case? * edit: I guess a basic example is a sliding-buffer that only keeps, and thus only reacts to, the last mouse event. Is this on the right track?
  - dminor 12y ago
    The example was more about showing that concurrency and threads are not synonymous, but you can imagine one of the functions producing a stream of values and the other waiting for and consuming them. In vanilla javascript, you have to resort to breaking your code up into callbacks, which looks trivial in a two function example but becomes unwieldy once you add a few layers and do error handling. With CSP you organize your code around channels according to the code's logic, rather than according to the needs of coordination. This makes things like error handling and reasoning about your logic much simpler.
    - lbradstreet 12y ago
      I totally agree that it helps with callback hell / reasoning, but I think your argument was more about coordination. Hence the sliding buffer example - something that would be very, very hard to /coordinate/ with callbacks.

arnarbi 12y ago

Short answer: Yes. Concurrency does not necessarily mean parallelism (multi-threading). CSP-derived mechanisms provide abstractions for units-of-work to yield control to other units-of-work. Here, a unit of work is a function invocation, but it can be a block, a thread-like object etc. With such primitives it is fairly easy to build cooperative (as opposed to pre-emptive) concurrency mechanisms. For a mature example, see e.g. http://www.stackless.com/ http://www.stackless.com/

craigching 12y ago

In the JavaScript "user space" you don't have access to threads (with the exception of web workers), but the JS engines themselves are multi-threaded and fully concurrent. This is why your UI doesn't freeze when doing XHR (assuming you're not doing synchronous XHR) and represents the need for elegantly handling asynchronicity.

dminor 12y ago

Say you have: function one() { console.log("one"); setTimeout(one, 1000); } function two() { console.log("two"); setTimeout(two, 2000); } one(); two(); They are executing concurrently, but never in parallel (since javascript is single threaded). Now, how do you coordinate them if you need to? This is what CSP helps you do.

lbradstreet 12y ago
I've spent a fair amount of time in core.async, and I feel like I'm on the edge of enlightenment here, but I don't quite understand how CSP helps with this example. Is the point that you can take multiple puts off the channel in one go? That's the only thing I can think of. Maybe you could present the CSP alternative, and a basic example use case? * edit: I guess a basic example is a sliding-buffer that only keeps, and thus only reacts to, the last mouse event. Is this on the right track?
- dminor 12y ago
  The example was more about showing that concurrency and threads are not synonymous, but you can imagine one of the functions producing a stream of values and the other waiting for and consuming them. In vanilla javascript, you have to resort to breaking your code up into callbacks, which looks trivial in a two function example but becomes unwieldy once you add a few layers and do error handling. With CSP you organize your code around channels according to the code's logic, rather than according to the needs of coordination. This makes things like error handling and reasoning about your logic much simpler.
  - lbradstreet 12y ago
    I totally agree that it helps with callback hell / reasoning, but I think your argument was more about coordination. Hence the sliding buffer example - something that would be very, very hard to /coordinate/ with callbacks.