IT工程師數位筆記本

Why?

Why the event loop?

The Event Loop is a software pattern that facilitates non-blocking I/O (network, file or inter-process
communication). Traditional blocking programming does I/O in the same fashion as regular function
calls; processing may not continue until the operation is complete. Here is some pseudo-code that
demonstrates blocking I/O:
1 var post = db.query('SELECT * FROM posts where id = 1');
2 // processing from this line onward cannot execute until the line above completes
3 doSomethingWithPost(post);
4 doSomethingElse();
What is happening here? While the database query is being executed, the whole process/thread
idles, waiting for the response. This is called blocking. The response to this query may take many
thousands of CPU cycles, rendering the entire process unusable during this time. The process could
have been servicing other client requests instead of just waiting for the database operation to
complete.
Programming in this way does not allow you to parallelize I/O (such as performing another database
query or communicating with a remote web service). The call stack becomes frozen, waiting for the
database server to reply.
This leaves you with two possible solutions to keep the process busy while it’s waiting: create more
call stacks or use event callbacks.

Solution 1: Create more call stacks

In order for your process to handle more concurrent I/O, you have to have more concurrent call
stacks. For this, you can use threads or some kind of cooperative multi-threading scheme like coroutines,
fibers, continuations, etc.
The multi-threaded concurrency model can be very difficult to configure, understand and debug,
mainly because of the complexity of synchronization when accessing and modifying shared state;
you never know when the thread you are running is going to be taken out of execution, which can
lead to bugs that are strange and difficult to reproduce.
On the other hand, cooperative multi-threading is a “trick” where you have more than one stack,
and each “thread” of execution explicitly de-schedules itself to give time to another parallel “thread”
of execution. This can relax the synchronization requirements but can become complex and errorprone,
since the thread scheduling is left in the hands of the programmer.

Solution 2: Use event-driven I/O

Event-driven I/O is a scheme where you register callbacks to be invoked when an interesting I/O
event happens.
An event callback is a function that gets invoked when something significant happens (e.g. the result
of a database query is available.)
To use event callbacks in the previous example, you could change it to:
1 callback = function(post) {
2 doSomethingWithPost(post); // this will only execute when the db.query function\
3 returns.
4 };
5 db.query('SELECT * FROM posts where id = 1', callback);
6 doSomethingElse(); // this will execute independent of the returned status of the\
7 db.query call.
Here you are defining a function to be invoked when the database operation is complete, then passing
this function as a callback argument to the db query operation. The db operation becomes responsible
for executing the callback when the result is available.
You can use an inline anonymous function to express this in a more compact fashion:
1 db.query('SELECT * FROM posts where id = 1',
2 function(post) {
3 doSomethingWithPost(post); // this will only execute when the db.query functi\
4 on returns.
5 }
6 );
7 doSomethingElse(); // this will execute independent of the returned status of the\
8 db.query call.
While db.query() is executing,the process is free to continue running doSomethingElse(), and even
service new client requests.

For quite some time, the C systems-programming “hacker” community has known that event-driven
programming is the best way to scale a server to handle many concurrent connections. It has been
known to be more efficient regarding memory: less context to store, and time: less context-switching.
This knowledge has been infiltrating other platforms and communities: some of the most wellknown
event loop implementations are Ruby’s Event Machine, Perl’s AnyEvent and Python’s
Twisted, and some others.

Tip: For more info about event-driven server implementations, see http://en.wikipedia.org/wiki/Reactor_-
pattern⁴.
Implementing an application using one of these event-driven frameworks requires frameworkspecific
knowledge and framework-specific libraries. For example: when using Event Machine, you
must avoid using all the synchronous libraries available in Ruby-land (i.e. most libraries). To gain
the benefit of not blocking, you are limited to using libraries that are specific for Event Machine. If
you use blocking libraries, your program will not be able to scale optimally because the event loop is
constantly being blocked, which may delay the processing of I/O events and makes your application
slow, defeating the original purpose of using event-driven I/O.
Node has been devised as a non-blocking I/O server platform from day one, which means that you
should expect everything built on top of it to be non-blocking (with some specific and very explicit
exceptions). Since JavaScript itself is very minimal and does not impose any way of doing I/O (it
does not have a standard I/O library like C, Ruby or Python), Node has a clean slate to build upon.

Why JavaScript?

Ryan Dahl began this pet project of his by building a platform that was programmable in C, but he
soon realized that maintaining the context between callbacks was too complicated and could lead
to poorly structured code. He then turned to Lua.
Lua already has several blocking I/O libraries and the mix of blocking and non-blocking could
confuse average developers and prevent many of them from building scalable applications, so Lua
wasn’t ideal either. Dahl then thought to JavaScript.
JavaScript has closures and first-class functions, making it indeed a powerful match with evented
I/O programming.
Closures are functions that inherit the variables from their enclosing environment. When a function
callback executes it will magically remember the context in which it was declared, along with all
the variables available in that context and any parent contexts. This powerful feature is at the heart
of Node’s success among programming communities. Let’s see a little bit of this goodness in action:
In the web browser, if you want to listen for an event, a button click for instance, you may do
something like:
1 var clickCount = 0;
2 document.getElementById('mybutton').onclick = function() {
3 clickCount ++;
4 alert('Clicked ' + clickCount + ' times.');
5 };
or, using jQuery:
⁴http://en.wikipedia.org/wiki/Reactor_pattern
Why? 7
1 var clickCount = 0;
2 $('button#mybutton').click(function() {
3 clickCount ++;
4 alert('Clicked ' + clickCount + ' times.');
5 });
In both examples we assign or pass a function as an argument. This function will then be executed
later once the relevant event (button clicking in this case) happens. The click handling function has
access to every variable in scope at the point where the function is declared, i.e. practically speaking,
the click handler has access to the clickCount variable, declared in the parent closure.
Here we are using a global variable, “clickCount”, where we store the number of times the user has
clicked a button. We can also avoid having a global variable accessible to the rest of the system,
by wrapping it inside another closure, making the clickCount variable only accessible within the
closure we created:
1 (function() {
2 var clickCount = 0;
3 $('button#mybutton').click(function() {
4 clickCount ++;
5 alert('Clicked ' + clickCount + ' times.');
6 });
7 })();
In line 7 we are invoking a function immediately after defining it. If this is strange to you, don’t
worry! We will cover this pattern later.
Here you don’t have to worry about synchronization: your callback function will not be interrupted
until it returns - you have that guarantee.

How I Learned to Stop Fearing and Love JavaScript

JavaScript has good and bad parts. It was created in 1995 by Netscape’s Brendan Eich, in a rush to
ship the latest version of the Netscape web browser. Due to this rush some good, even wonderful,
parts got into JavaScript, but also some bad parts.
This book will not cover the distinction between JavaScript good and bad parts. (For all we know, we
will only provide examples using the good parts.) For more on this topic you should read Douglas
Crockford book named “JavaScript, The Good Parts”, edited by O’Reilly.

In spite of its drawbacks, JavaScript quickly - and somewhat unpredictably - became the de-facto
language for web browsers. Back then, JavaScript was used primarily to inspect and manipulate
HTML documents, allowing the creation the first dynamic, client-side web applications.
In late 1998, the World Wide Web Consortium (W3C), standardized the Document Object Model
(DOM), an API devised to inspect and manipulate HTML documents on the client side. In response
to JavaScript’s quirks and the initial hatred towards the DOM API, JavaScript quickly gained a
bad reputation, also due to some incompatibilities between browser vendors (and sometimes even
between products from the same vendor!).
Despite mild to full-blown hate in some developer communities, JavaScript became widely adopted.
For better or for worse, today JavaScript is the most widely deployed programming language on
planet Earth – and growing.
If you learn the good features of the language - such as prototypical inheritance, function closures,
etc. - and learn to avoid or circumvent the bad parts, JavaScript can be a very pleasant language to
work in.
Function Declaration Styles
A function can be declared in many ways in JavaScript. The simplest is declaring it anonymously:
1 function() {
2 console.log('hello');
3 }
Here we declare a function, but it’s not of much use, because we do not invoke it. What’s more, we
have no way to invoke it as it has no name.
We can invoke an anonymous function in-place:
1 (function() {
2 console.log('hello');
3 })();
Here we are executing the function immediately after declaring it. Notice we wrap the entire
function declaration in parenthesis.
We can also name functions like this:
1 function myFunction () {
2 console.log('hello');
3 }
Here we are declaring a named function with the name: “myFunction”. myFunction will be available
inside the scope in which it’s declared

1 myFunction();
and also within inner scopes:
1 function myFunction () {
2 console.log('hello');
3 }
4
5 (function() {
6 myFunction();
7 })();
A result of JavaScript treating functions as first-class objects means we can assign a function to a
variable:
1 var myFunc = function() {
2 console.log('hello');
3 }
This function is now available as the value of the myFunc variable.
We can assign that function to another variable:
1 var myFunc2 = myFunc;
And invoke them just like any other function:
1 myFunc();
2 myFunc2();
We can mix both techniques, having a named function stored in a variable:
1 var myFunc2 = function myFunc() {
2 console.log('hello');
3 }
4 myFunc2();
(Note though, we cannot access myFunc from outside the scope of myFunc itself!)
We can then use a variable or a function name to pass variables into functions like this:

1 var myFunc = function() {
2 console.log('hello');
3 }
4
5 console.log(myFunc);
or simply declare it inline if we don’t need it for anything else:
1 console.log(function() {
2 console.log('hello');
3 });

Functions are first-class objects

In fact, there are no second-class objects in JavaScript. JavaScript is the ultimate object-oriented
language, where (almost) everything is indeed, an object. As that, a function is an object where you
can set properties, pass it around inside arguments and return them.
Example:
1 var scheduler = function(timeout, callbackfunction) {
2 return function() {
3 setTimeout(callbackfunction, timeout)
4 }
5 };
6
7 (function() {
8 var timeout = 1000; // 1 second
9 var count = 0;
10 var schedule = scheduler(timeout, function doStuff() {
11 console.log(++ count);
12 schedule();
13 });
14 schedule()
15 })();
16
17 // "timeout" and "count" variables
18 // do not exist in this scope.
In this little example we create a function and store it in a variable called “scheduler” (starting on
line 1). This function returns a function that sets up a timer that will execute a given function within
a certain number of miliseconds (line 3). This timeout will schedule a callback function to be called
after a time delay of 1 second, as specified by the timeout variable.
Why? 11
In line 9 we declare a function that will immediately be executed in line 15. This is a normal way
to create new scopes in JavaScript. Inside this scope we create 2 variables: “timeout” (line 8) and
“count” (line 9). Note that these variables will not be accessible to the outer scope.
Then, on line 10, we invoke the scheduler function, passing in the timeout value as first argument
and a function called doStuff as second argument. This returns a function that we store in the local
schedule variable, which we later invoke (line 14), provoking the setTimeout to be called. When the
timeout occurs, this function will increment the variable count and log it, and also call the schedule
all over again.
So in this small example we have: functions passed as argument, functions to create scope, functions
to serve as asynchronous callbacks and returning functions. We also here present the notions of
encapsulation (by hiding local variables form the outside scope) and recursion (the function is calling
itself at the end).
In JavaScript you can even set and access attributes in a function, something like this:
1 var myFunction = function() {
2 // do something crazy
3 };
4 myFunction.someProperty = 'abc';
5 console.log(myFunction.someProperty);
6 // #=> "abc"
JavaScript is indeed a powerful language, and if you don’t already, you should learn it and embrace
its good parts.

JSHint

It’s not to be covered here, but JavaScript indeed has some bad parts, and they should be avoided at
all costs.
One tool that’s proven invaluable to me is JSHint. JSHint analyzes your JavaScript file and outputs a
series of errors and warnings, including some known misuses of JavaScript, such as using globallyscoped
variables (like when you forget the “var” keyword), and freezing values inside iteration that
have callbacks that use them, and many others that are useful.
JHLint can be installed using
1 $ npm install -g jshint
If you don’t have Node installed see section about NPM⁵.
and can be run from the command line like this:
⁵index.html#npm
Why? 12
1 $ jshint myfile.js
You can also define what rules this tool should obey by defining and customizing a .jshintrc inside
your home directory. For more information on JSHint plrease refer to the official documentation at
http://www.jshint.com/docs/⁶.

JavaScript versions

JavaScript is a standard with its own name - ECMAScript - and it has gone through various iterations.
Currently Node natively supports everything the V8 JavaScript engine supports ECMA 3rd edition
and parts of the new ECMA 5th edition.
These parts of ECMA 5 are nicely documented on the following github wiki page: https://github.com/joyent/node/wiki/5-Mozilla-Features-Implemented-in-V8⁷