2

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?

rogermushroom
  • 5,486
  • 4
  • 42
  • 68
  • 1
    How wrote that? The asynchronous I/O is, as far as I know, a node-specific extension (though it does use a pure JS interface). –  Apr 09 '12 at 16:35
  • 1
    The language doesn't provide non-blocking IO. Certain frameworks do, however. – Cameron Apr 09 '12 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 Apr 09 '12 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 Apr 09 '12 at 16:39
  • @ChaosPandion Nothing Cameron said was incorrect. There is a difference between actually implementing a feature and a platform making it EASIER to implement a feature. – Andrew T Finnell Apr 09 '12 at 16:43
  • 3
    @ChaosPandion: Very true! But there's no mention of async I/O in the JS spec, as far as I know. – Cameron Apr 09 '12 at 16:43

4 Answers4

6

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.

Jamison Dance
  • 19,896
  • 25
  • 97
  • 99
5

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)

RestingRobot
  • 2,938
  • 1
  • 23
  • 36
  • 1
    both the cancer link and the non-cancer link are dead to me – Alexander Mills Jun 21 '15 at 20:23
  • 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. – RestingRobot Jun 22 '15 at 17:08
  • also, Node.js is multithreaded - all the i/o calls happen on a different thread than the main event loop thread – Alexander Mills Jun 22 '15 at 18:25
  • Can you source that assertion? Because Node.js is Javascript, it is by nature single threaded. – RestingRobot Jun 23 '15 at 18:44
  • Alex, see here: http://stackoverflow.com/questions/5200821/grasping-the-node-js-alternative-to-multithreading – RestingRobot Jun 23 '15 at 18:46
  • JLange, think of the I/O libraries for the back-end of Node as AJAX is for the front-end. You as the developer don't see what AJAX is doing, but it's doing an async request and it's not on the event loop, it's on a separate thread. – Alexander Mills Jun 23 '15 at 18:51
  • Yes you are correct that the I/O libraries can leverage separate threads, but Node.js itself is single threaded. – RestingRobot Jun 23 '15 at 19:02
  • To expand, when you call an I/O library function, Node.js continues to execute its event loop. The I/O function runs on a separate thread, while the node continues to run. However, when the I/O function returns, node stops its current execution to process the I/O function. Once the function is processed, the event loop can resume. This is the crux of the issue, node can only do 1 thing at a time; run its event loop or process a response. This is why node is single threaded. – RestingRobot Jun 23 '15 at 19:09
  • I disagree Jlange. The event loop is single threaded, but the event loop would lock up if there were not other threads available to do I/O. Node.js is multithreaded - Node.js is NOT just the event loop bro :) The non-blocking I/O facility is basically the crux of Node.js, and those involve a pool of threads. Likewise, Javascript in the browser is not just the event-loop, there is more to it than that. – Alexander Mills Jun 23 '15 at 19:17
  • your simplistic view is F-ing up everyone else's understanding. just saying "oh node.js is just single-threaded because of the event-loop", that's wrong and overly simplistic – Alexander Mills Jun 23 '15 at 19:21
  • I mean you do realize that the terms "single-threaded" and asynchronous are completely at odds with each other? You have to reconcile that. – Alexander Mills Jun 23 '15 at 19:35
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/81335/discussion-between-jlange-and-alex-mills). – RestingRobot Jun 23 '15 at 21:19
  • One final comment to anyone else viewing this thread, Asynchronous programming does not necessarily mean multi-threaded. Node.js is a prime example of this concept. – RestingRobot Jun 23 '15 at 21:59
  • I disagree with that statement. Concurrent does not necessarily mean multi-threaded. Parallel and async on the other hand, do mean multi-threaded. – Alexander Mills Jun 23 '15 at 22:02
  • Node.js is a prime example of asynchronous i/o which uses a pool of threads – Alexander Mills Jun 23 '15 at 22:02
  • Alex, i'm sorry you disagree, but i will have to defer to the experts when it comes to this concept. See http://stackoverflow.com/questions/8982489/how-does-asynchronous-programming-work-in-a-single-threaded-programming-model http://stackoverflow.com/questions/600795/asynchronous-vs-multithreading-is-there-a-difference http://stackoverflow.com/questions/8963209/does-async-programming-means-multi-threading – RestingRobot Jun 23 '15 at 22:06
  • Actually just try googling "does asynchronous mean multithreaded" and you will see with overwhelming support, that you are incorrect in your assumption. – RestingRobot Jun 23 '15 at 22:07
  • They are wrong. Asynchronous means multi-threaded. It may not be in your program, but the threads are on the OS, and that makes a difference. – Alexander Mills Jun 23 '15 at 22:13
  • Alex, please prove me wrong by showing me code in Node.js that spawns a thread and executes. – RestingRobot Jun 23 '15 at 22:14
  • Also to your statement "Concurrent does not necessarily mean multi-threaded. Parallel and async on the other hand, do mean multi-threaded" "Concurrent" and "parallel" are synonyms and mean the same thing. – RestingRobot Jun 23 '15 at 22:16
  • nope, concurrent and parallel do not mean the same thing, and this shows your ignorance, later – Alexander Mills Jun 23 '15 at 22:18
  • OK I have found a much better explanation than i could ever provide: http://blog.slaks.net/2014-12-23/parallelism-async-threading-explained/ See the section "Availability in Programming Languages" – RestingRobot Jun 23 '15 at 22:18
  • In the case of Javascript, concurrent and parallel DO mean the same thing, as there is only 1 thread in which to process. – RestingRobot Jun 23 '15 at 22:23
  • "They are wrong. Asynchronous means multi-threaded. It may not be in your program, but the threads are on the OS, and that makes a difference" Yes you are exactly right, the threads are controlled by the OS and NOT by Node.js – RestingRobot Jun 23 '15 at 22:24
  • they are controlled by V8 which is a part of Node, you cannot separate the two – Alexander Mills Jun 23 '15 at 22:37
  • NO V8 is not a part of Node.js. V8 is written in c++ and is an engine that RUNS Node.js and Javascript. Node.js requires V8 to run, but that does not mean that it has the same OS priveleges. – RestingRobot Jun 23 '15 at 22:44
  • V8 is a program installed on the server with access to threads. Node.js is a language that is interpreted by V8. V8 can spawn threads, Node.js cannot. – RestingRobot Jun 23 '15 at 22:45
  • Node.js can spawn threads, look at the child_process lib https://nodejs.org/api/child_process.html you have absolutely no idea what you are talking about – Alexander Mills Jun 23 '15 at 22:47
  • Node.js is an *API*, it is not creating the child processes, V8 and the OS are. Node.js simply triggers the process spawn in V8, and then handles the response. – RestingRobot Jun 23 '15 at 22:52
1

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.

Bergi
  • 630,263
  • 148
  • 957
  • 1,375
  • 1
    node.js is event-based; browsers are event-based; JavaScript doesn't care. – Amadan Apr 09 '12 at 16:44
  • OK, thats true. Ecmascript spec itself does not tell us anything about events, but first-class-functions and closures make callbacks very easy. – Bergi Apr 09 '12 at 16:59
0

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.

qwert9988
  • 118
  • 13