4 ms·

This doesn't mention server-side JavaScript at all. There are lots of blocking routines in Node.js, the standard library is full of them. But it is interesting

This doesn't mention server-side JavaScript at all. There are lots of blocking routines in Node.js, the standard library is full of them. But it is interesting that it doesn't mention the oft repeated meme "JavaScript is single-threaded". Would be nice with an example showing parallel number-crunching without WebWorkers. Is that possible?

girvo 9y ago
I haven't read the article, but my simplistic understanding is that Node.js for your _app_ code is single-threaded, but the async IO that happens is done via an internal thread-pool. So, number crunching in your code will pretty much always block the rest of your code (but your existing IO routines will continue, until they complete, and their callbacks can't run until your number crunching is done). I am very tired, and not thinking straight, so I've probably messed up the explanation a bit. Lately, I've been playing with libev and thread-pools together in Nim; so you write async/await stuff everywhere with futures, including number crunching, which gets delegated out to the thread pool and yields back to your main thread when it's done. It's quite nice, but I forgot how complex this stuff gets!
- elmigranto 9y ago
  > the async IO that happens is done via an internal thread-pool Not quite, since using threads internally (thread per IO operation) would defeat a purpose of async system, which is created specifically to not pay threading cost (context switches, etc.). In layman terms, kernel will simply invoke your C callback function when "stuff happens", and libuv propagates that to JS in platform-agnostic manner. There are still threads and thread pools in V8 and node for stuff like calculating PI (or, more realistically, password hashing and other number crunching), but that is mostly unrelated to async IO itself. Some google queries: select, poll, epoll, kqueue…
  - paulddraper 9y ago
    > using threads internally (thread per IO operation) would defeat a purpose of async system Yes and no. Having single threaded JS (no matter if runtime uses epoll) allows for JS concurrency concerns to be limited to a small number of places, i.e no pre-emptive. This makes concurrency in JS easier to reason about.
  - zbjornson 9y ago
    Are you sure the thread pool isn't used for IO? I thought that was it's primary use. This explanation is a bit old but I think still correct: http://stackoverflow.com/a/20346545 http://stackoverflow.com/a/20346545 and http://dailyjs.com/post/libuv http://dailyjs.com/post/libuv
    - elmigranto 9y ago
      That is true only for file system calls. Everything else is using non-blocking OS-provided mechanism. http://docs.libuv.org/en/v1.x/design.html http://docs.libuv.org/en/v1.x/design.html
jordache 9y ago
js is single threaded. parallel number crunching is not possible. You can fake it by kicking off multiple executions on a data set and chunk the work load across the data set, so they progress incrementally and equivalently. The data might be small enough (or browser fast enough) to give the impression of things being done in parallel.
- munchor 9y ago
  OP referred to Web Workers[1] which do allow real parallel number crunching (at minimum on a different thread, might even be in a different core). It's a somewhat "new" feature of JavaScript but most modern browsers already implement it[2]. [1] https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... [2] http://caniuse.com/#search=webworkers http://caniuse.com/#search=webworkers
  - jordache 9y ago
    do you read? OP asked for an example sans web workers. Plus web workers do not change the fact that JS is single threaded.
tyingq 9y ago
>Would be nice with an example showing parallel number-crunching without WebWorkers. Is that possible? Generators and yield for some types of crunching. Not parallel, but at least not a tight spinning loop.
Pherdnut 9y ago
Not without making calls to c-bound processes that plug into the event loop or two independent JS run-times talking to each other which is also possible on the web through iframes or in Node via spawning child processes. Single-threaded is desired behavior in the case of web ui and of Node, which is multi-process c/++ under the hood and JS responding to message queues. It's pretty simple. Functions block. The messaging queue that triggers function calls in event-driven, setTimeout, XHR, talking to another JS runtime cases doesn't. So yes, you have to be careful to not lock up your entire server by processing images with JS function calls in the same runtime. But the huge benefit you get out of this tradeoff is that you don't ever have to worry about two things trying to change something at the same time. Everybody is locked until your functions are finished and with async that doesn't typically take very long. The synchronous lib calls in Node are mostly for convenience. I use them all the time when doing simple file I/O stuff where I just want to read something from a file, do something to it and stick it in a var or a new file. In a server or more complex application, however, you always want to use async callbacks.

girvo 9y ago

I haven't read the article, but my simplistic understanding is that Node.js for your _app_ code is single-threaded, but the async IO that happens is done via an internal thread-pool. So, number crunching in your code will pretty much always block the rest of your code (but your existing IO routines will continue, until they complete, and their callbacks can't run until your number crunching is done). I am very tired, and not thinking straight, so I've probably messed up the explanation a bit. Lately, I've been playing with libev and thread-pools together in Nim; so you write async/await stuff everywhere with futures, including number crunching, which gets delegated out to the thread pool and yields back to your main thread when it's done. It's quite nice, but I forgot how complex this stuff gets!

elmigranto 9y ago
> the async IO that happens is done via an internal thread-pool Not quite, since using threads internally (thread per IO operation) would defeat a purpose of async system, which is created specifically to not pay threading cost (context switches, etc.). In layman terms, kernel will simply invoke your C callback function when "stuff happens", and libuv propagates that to JS in platform-agnostic manner. There are still threads and thread pools in V8 and node for stuff like calculating PI (or, more realistically, password hashing and other number crunching), but that is mostly unrelated to async IO itself. Some google queries: select, poll, epoll, kqueue…
- paulddraper 9y ago
  > using threads internally (thread per IO operation) would defeat a purpose of async system Yes and no. Having single threaded JS (no matter if runtime uses epoll) allows for JS concurrency concerns to be limited to a small number of places, i.e no pre-emptive. This makes concurrency in JS easier to reason about.
- zbjornson 9y ago
  Are you sure the thread pool isn't used for IO? I thought that was it's primary use. This explanation is a bit old but I think still correct: http://stackoverflow.com/a/20346545 http://stackoverflow.com/a/20346545 and http://dailyjs.com/post/libuv http://dailyjs.com/post/libuv
  - elmigranto 9y ago
    That is true only for file system calls. Everything else is using non-blocking OS-provided mechanism. http://docs.libuv.org/en/v1.x/design.html http://docs.libuv.org/en/v1.x/design.html

jordache 9y ago

js is single threaded. parallel number crunching is not possible. You can fake it by kicking off multiple executions on a data set and chunk the work load across the data set, so they progress incrementally and equivalently. The data might be small enough (or browser fast enough) to give the impression of things being done in parallel.

munchor 9y ago
OP referred to Web Workers[1] which do allow real parallel number crunching (at minimum on a different thread, might even be in a different core). It's a somewhat "new" feature of JavaScript but most modern browsers already implement it[2]. [1] https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers_API/Using_web_workers https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers... [2] http://caniuse.com/#search=webworkers http://caniuse.com/#search=webworkers
- jordache 9y ago
  do you read? OP asked for an example sans web workers. Plus web workers do not change the fact that JS is single threaded.

tyingq 9y ago

>Would be nice with an example showing parallel number-crunching without WebWorkers. Is that possible? Generators and yield for some types of crunching. Not parallel, but at least not a tight spinning loop.

Pherdnut 9y ago

Not without making calls to c-bound processes that plug into the event loop or two independent JS run-times talking to each other which is also possible on the web through iframes or in Node via spawning child processes. Single-threaded is desired behavior in the case of web ui and of Node, which is multi-process c/++ under the hood and JS responding to message queues. It's pretty simple. Functions block. The messaging queue that triggers function calls in event-driven, setTimeout, XHR, talking to another JS runtime cases doesn't. So yes, you have to be careful to not lock up your entire server by processing images with JS function calls in the same runtime. But the huge benefit you get out of this tradeoff is that you don't ever have to worry about two things trying to change something at the same time. Everybody is locked until your functions are finished and with async that doesn't typically take very long. The synchronous lib calls in Node are mostly for convenience. I use them all the time when doing simple file I/O stuff where I just want to read something from a file, do something to it and stick it in a var or a new file. In a server or more complex application, however, you always want to use async callbacks.