I read that the javascript language has characteristics that assist in the implementation of non-blocking IO which contributes to the success of projects like node.js. My question is what are these characteristics and why is non-blocking IO trickier to implement in other languages?
6
- 1How wrote that? The asynchronous I/O is, as far as I know, a node-specific extension (though it does use a pure JS interface).user395760– user3957602012-04-09 16:35:34 +00:00Commented Apr 9, 2012 at 16:35
- 1The language doesn't provide non-blocking IO. Certain frameworks do, however.Cameron– Cameron2012-04-09 16:36:13 +00:00Commented Apr 9, 2012 at 16:36
- Can you provide the document you read? Maybe they meant language syntax and semantics provides for non-blocking IO.Andrew T Finnell– Andrew T Finnell2012-04-09 16:37:08 +00:00Commented Apr 9, 2012 at 16:37
- 2@Cameron - I slightly disagree, some languages will aid you in implementing non-blocking IO while others will fight you at every turn.ChaosPandion– ChaosPandion2012-04-09 16:39:06 +00:00Commented Apr 9, 2012 at 16:39
- 3@ChaosPandion: Very true! But there's no mention of async I/O in the JS spec, as far as I know.Cameron– Cameron2012-04-09 16:43:45 +00:00Commented Apr 9, 2012 at 16:43
| Show 1 more comment
4 Answers
JavaScript itself does not provide non-blocking IO. The underlying system calls that node.js uses do the non-blocking IO. JavaScript's first-class functions mean that it is easy to pass callbacks around when IO has completed.
Other languages can do non-blocking IO just fine. node.js just argues that callbacks make it super-easy to reason about and handle non-blocking operations.
Ruby has EventMachine, which passes blocks around instead of functions. C can do non-blocking IO with function pointers, but then you don't get closures, so it is a bit more of a pain.
Comments
The reason that javascript is sometimes labeled as a non-blocking IO is because of the concept of anonymously defined, (event based), functions. Node.js specifically labels this as their reasoning why javascript is a good server side language. This however, is only a half truth, as it is not technically non-blocking, but it will continue to execute code while waiting for a callback from an anonymous callback/ajax function. I'm not sure if this is what you read, but an explanation offered in one Node tutorial is:
"The other method, the one taken by Node and some extremely fast modern servers such as Nginx and Thin, is to use a single non-blocking thread with an event loop. This is where the decision to use JavaScript really shines, since JavaScript was designed to be used in a single threaded event loop-based environment: the browser. JavaScript’s ability to pass around closures makes event-based programming dead simple. You basically just call a function to perform some type of I/O and pass it a callback function and JavaScript automatically creates a closure, making sure that the correct state is preserved even after the calling function has long since gone out of scope."
source: http://net.tutsplus.com/tutorials/javascript-ajax/this-time-youll-learn-node-js/
In reference to your multithreading tag, Node.js and Javascript are NOT multithreaded, they use a system of closures to preserve state while waiting for a callback. Therefore, they are NOT completely non-blocking. There are plenty of scenarios where blocking can occur, but for most small implementations, a developer will never encounter a blocking situation.
see here for possible info on why node.js is bad: http://teddziuba.com/2011/10/node-js-is-cancer.html (Link broken)
and here for a rebuttle: http://rhyolight.posterous.com/nodejs-is-not-cancer (Link broken)
29 Comments
Alexander Mills
both the cancer link and the non-cancer link are dead to me
RestingRobot
Sorry about that. I would try googling the article titles and see if they are archived somewhere. Those links are private blogs, so I think its safe to assume they would migrate after 3 years.
Alexander Mills
also, Node.js is multithreaded - all the i/o calls happen on a different thread than the main event loop thread
RestingRobot
Can you source that assertion? Because Node.js is Javascript, it is by nature single threaded.
RestingRobot
Alex, see here: stackoverflow.com/questions/5200821/…
|
Asynchronous functions are usually event-based in JavaScript, which means registering callback-handlers. Your code runs on after the registration, but does not wait for the event - everything to be done after a event must be invoked from the handler. I hope that says all.
Of course there are exceptions, like window.alert / confirm / prompt in browsers.
https://youtu.be/dFnkZ15-_0o?t=2125 This excerpt from Andrew Mead's node.js course does a great job of visually explaining the differences between non-blocking and blocking I/O operations in JS. The clip is from 35:25 - 47:16.
