Is it just me or does the Go community use a different definition of "concurrency" vs "parallelism"? The "standard" one is afaict "parallelism is one way of getting concurrency", whereas Go seems to use it specifically to talk about interleaving.
-
-
Because those two file reads are happening at the same time ("concurrently"). But the actual code happens one at a time. The first done() function can't happen literally at the same time as another done() function ("what would that even mean?!" is more or less right) ...
-
So concurrent just means you kicked off some work for someone else to do, and while you're waiting, you can do other stuff or kick off more work. Parallelism means your code is doing two things simultaneously. In JS, web workers offer parallelism (as
@ManishEarth said) but ... -
only by preventing from sharing almost all memory directly with the other parallel work. From the perspective of the code that started a worker, the parallel process is just another concurrent task that "someone else" is doing. You just have more control ...
-
Most interesting approaches to parallelism are structured around reducing the likelihood of accidentally working on the same object at the same time ("what would that even mean?!" is sometimes called "undefined behavior" or "UB" in C++ jargon)
-
That was probably too much. Ask away.
-
Just a followup: how does the interleaving happen in the browser? Who/what process handles it? Does the browser delegate it to the OS?
-
The browser controls the JavaScript event loop. The OS scheduler isn't involved.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.