Node's goal is to provide easy, scalable concurrency. In the above example,
the 2 second delay does not prevent the server from handling new requests.
-Node notifies the operating system (through epoll(7)) that it
-should be notified when the 2 seconds are up, or if a new connection is
+Node tells the operating system (through epoll or
+kqueue or /dev/poll or select) that it
+should be notified when the 2 seconds are up or if a new connection is
made—then it goes to sleep. If someone new connects, then it executes
-the callback again. Each connection is only a small allocation on the heap.
+the callback, if the timeout expires, it executes the inner callback.
+Each connection is only a small heap allocation.
-
This is in contrast to most scripting languages (and all other -server-side javascript systems) where OS threads are employed to have +
This is in contrast to most scripting languages where OS threads are employed for concurrency. But thread-based networking is relatively inefficient and +very difficult to use. -Node will show much better memory performance under high-loads +Node will show much better memory efficency under high-loads -than other systems (i.e. all other javascript server-side systems) +than other systems which allocate 2mb thread stacks for each connection. -
For networking, Node is similar to systems like +Node is similar to systems like Ruby's Event Machine or Python's Twisted. @@ -74,6 +76,9 @@ Node blocks, a Node programmer is going to find it difficult to write slow servers—even if they don't understand how the concurrency system works. +
Notice in the above example the puts() call is made
+immediately.
+
Node's HTTP API has grown out of my difficulties while developing for Merb and Ebb. Because of limiting low-level design choices, streaming data through Rack-based frameworks is difficult or impossible. Streaming is