7

In the short chapter, What is Node by McLaughlin, he writes:

"Node has no blocks, no threads competing for the same resource (Node is happy to just let things happen however they happen), nothing that has to start up upon request. Node just sits around waiting (quite literally; unused Node responders are sleeping). When a request comes in, it’s handled. This results in very fast code, without uber- programmers writing the server-side behavior."

While I think he's picking on PHP here - from what I understand there isn't a way for PHP to not call up new references to its databases, files, etc, whenever any php page is loaded - is this really different than other web technologies? Consider Django/Flask for example or a simple Python threaded-server using builtin methods - is it really any different than the no-blocks advantages of Node? You run a program and it binds a socket, running the function only as needed. (Doesn't Java also do this?)

  • It's pretty easy to claim that there are no competing threads when there is only one thread. – Rein Henrichs Jun 28 '15 at 6:11
  • Ok - so you don't have to set thread locks, as Python/Java would. (Does node.js not have this ability?) – NoBugs Jun 28 '15 at 6:14
  • Node has a single-threaded runtime. You don't need locks if you don't have multiple threads. See, e.g., stackoverflow.com/questions/14795145/… for more info. – Rein Henrichs Jun 28 '15 at 6:16
  • 5
    It isn't really special. You can use the same IO and threading model in other languages as well. The most special thing is that everything in node.js has been written with that model in mind whereas in other languages you have to carefully choose which libraries you're using. – CodesInChaos Jun 28 '15 at 10:37
  • "what I understand there isn't a way for PHP to not call up new references to its databases" I think PHP has something called persistent database connections, though I'm not sure haven't used it in a while. – ALXGTV Jul 3 '15 at 9:35
9

Let's immediately get the Turing-completeness disclaimer out of the way and say any language can probably approximate any runtime feature of any other language. Good? Good.

The main difference between the Node.js approach and a Python threaded-server (or a typical Java HTTP server implementation) is that Node.js is single threaded while the latter two are multithreaded. More specifically, the latter two will typically dedicate one thread per request. If, in the handling of that request, you need to do something slow like read from harddrive or connect to a remote database, the thread will sleep until the slow thing is done and the rest of the business logic is ready to proceed. In contrast, the Node.js approach is to schedule callbacks that are to be invoked once the slow thing is done; Node.js' single thread is never sleeping except if there are literally no requests to process.

The main difference between Node.js and PHP is that in Node.js, the code runs in a persistent context that exists as long as your Node.js server is running. So for example, if you write a value to a global variable in one request, and then read out the value of the global variable in another request, the read will see the value that was written by the write. In contrast, in PHP, a new context is created for each request, and so writes to globals in one request are lost when the script handling the request terminates.

1

Unlike all other servers you have mentioned, Node is single threaded, but asynchronous - as some have mentioned here, it schedules callbacks instead of waiting for operation to execute and runs callbacks when the operation is complete, however a number of other operations might have been processed in between with the same thread.

Caveats:

Although it's a wonderland for asynchronous programming where you don't need to watch your variables being used by multiple threads, if one not familiar with the way Node works would be to apply regular synchronous approach, this can turn into a VERY very slow application as every request will pile up to wait till the first request will finish it's action...

  • In other words, instead of reading file, then reading db, then doing stuff, the equivalent would be single node thread setting its callback to read-file, handing off to next process, then setting callback to read-db and handing off to next process, then doing stuff.? – NoBugs Jul 3 '15 at 20:37
  • Something like that: 1) Hey SQL server, get me that record(writes down the callback for later.) 2) Hey User #2, here is your static file you asked for. 3) Hey SQL server, thanks for getting back to me on that one, where did I put the callback again? 4) Hey User 1, here is your record. – Alexus Jul 3 '15 at 20:44
  • @NoBugs NodeJS employs cooperative multi-tasking. Its great if everyone is cooperating. – user40980 Jul 3 '15 at 20:45
  • Regular server would be: 1) Hey Thread 1, can you please go fetch the record, then prepare it, then return to the user and don't come back until done. 2) Hey thread 2, can you go fetch that image and return to user 2, don't comeback until done. – Alexus Jul 3 '15 at 20:45
  • @MichaelT Thanks mate! Way better explanation than my mumbling ;D – Alexus Jul 3 '15 at 20:46
0

A Node program is at its core a normal program, it isn't even a web-server unless you write code specifically to make it so (though that is pretty easy with the built-in HTTP library). Your program will get the HTTP requests, and your code can respond any way you like, using all the resources otherwise available to the program.

If JavaScript was old-school linear execution you would, without some unwieldy complicated code, only be able to process one request at a time. This is pretty bad considering that most of the time taken handling a web request is usually spent waiting on I/O.

JavaScript program flow is however based on events, you set a handler as a piece of code that is run when an event happens, and when you are done handling that event JavaScript automatically goes on to the next event in the event queue. If you for instance need a piece of data from the database in order to handle a request you don't just wait for the database to answer, you set an event handler that fires when the database answers (often in the form of a callback function), and you complete the job when that happens, in the intervening time lots of other events may be handled.

This is what non-blocking means, you don't halt the entire program because you need to wait for something.

The great thing is, you still write your code in a mostly linear fashion, you usually don't have to pay much attention to the actual order of execution.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.