Mastering JavaScript

Chapter 9
If a program blocks I/O, the Node server will refuse new requests. There are several
ways of solving this problem. The most popular traditional approach is to use
several threads to process requests—this technique is known as multithreading.
If are you familiar with languages such as Java, chances are that you have written
multithreaded code. Several languages support threads in various forms—a thread
essentially holds its own memory and state. Writing multithreaded applications on a
large scale is tough. When multiple threads are accessing a common shared memory
or values, maintaining the correct state across these threads is a very difficult task.
Threads are also costly when it comes to memory and CPU utilization. Threads that
are used on synchronized resources may eventually get blocked.
The browser handles this differently. I/O in the browser happens outside the main
execution thread and an event is emitted when I/O finishes. This event is handled by
the callback function associated with that event. This type of I/O is non-blocking and
asynchronous. As I/O is not blocking the main execution thread, the browser can
continue to process other events as they come without waiting on any I/O. This is a
powerful idea. Asynchronous I/O allows browsers to respond to several events and
allows a high level of interactivity.
Node uses a similar idea for asynchronous processing. Node's event loop runs as
a single thread. This means that the application that you write is essentially singlethreaded.
This does not mean that Node itself is single-threaded. Node uses libuv
and is multithreaded—fortunately, these details are hidden within Node and you
don't need to know them while developing your application.
Every call that involves an I/O call requires you to register a callback. Registering a
callback is also asynchronous and returns immediately. As soon as an I/O operation
is completed, its callback is pushed on the event loop. It is executed as soon as
all the other callbacks that were pushed on the event loop before are executed.
All operations are essentially thread-safe, primarily because there is no parallel
execution path in the event loop that will require synchronization.
Essentially, there is only one thread running your code and there is no parallel
execution; however, everything else except for your code runs in parallel.
Node.js relies on libev (http://software.schmorp.de/pkg/libev.html) to
provide the event loop, which is supplemented by libeio (http://software.
schmorp.de/pkg/libeio.html) that uses pooled threads to provide asynchronous
I/O. To learn even more, take a look at the libev documentation at http://pod.tst.
eu/http://cvs.schmorp.de/libev/ev.pod.
[ 203 ]
www.it-ebooks.info