3 ms·
Say you have: function one() { console.log("one"); setTimeout(one, 1000); } function two() { console.log("two"); setTimeout(two, 2000)
by 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 agoI'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 agoThe 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 agoI 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.