Node.js event loop does not poll

Node.js uses a well-known event loop, but does it work by polling? Some have that impression.

An event loop¹ works by requesting its events from a message pump (per Wikipedia).

Here's how the event loop is implemented: 'Internally, node.js relies on libev to provide the event loop, which is supplemented by libeio[,] which uses pooled threads to provide asynchronous I/O.'².

Here's Wikipedia's article on polling³ and another definition⁴.

Now, 'poll' is a system call which asks Unix to check a set of file descriptors:

'poll, ppoll - wait for some event on a file descriptor...If none of the events requested (and no error) has occurred for any of the file descriptors, then poll() blocks until one of the events occurs.'⁵

Possibly, the system call's name may have misled people into thinking a userland program is doing polling. Nevertheless, when the 'poll' (Unix system call) is invoked, this is not polling in itself.

Hypothetically, in order to get information from a message pump, an event loop could employ the Unix system call 'poll' to check a file descriptor, to which the message pump would write events.

Ultimately, this may be the source of the conceptual confusion here, or it may be caused by the fact that (actual) polling is the easiest method to think of, when programming.

For our case in particular, if an event loop calls Unix 'poll', this is not an instance of the event loop polling anything. Neither node.js, nor any event loop, but only Unix, polls the file descriptors (if indeed it even really does, anymore).

Anyway, an event loop, such as node.js's, does not poll its message pump. Instead, it merely makes a (blocking) request to it. Calling just any request 'polling' pollutes the meaning of the word (and that may be happening here.)

tl;dr – So, let's try anymore not to say that node.js is polling its events—okay? Instead, let's simply say that node.js waits for its events. (A lost cause, I know—but at least I've said it.)

1 http://en.wikipedia.org/wiki/Event_loop
2 http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/
3 http://en.wikipedia.org/wiki/Polling_%28computer_science%29
4 http://whatis.techtarget.com/definition/polling
5 http://linux.die.net/man/2/poll

Copyright (c) 2012 Mark D. Blackwell.

Chrome browser cookie exceptions, howto

Google's fast, new Chrome browser has a development process that seems to fix problems rapidly.

An unmet need in the user interface, however, is explicating (right on the page) how to enter domains for cookie handling exceptions.

The proper way to be secure (though you may disagree) IMHO follows:

* Wrench-Options-Under the Hood-Content Settings-Cookies.
* Select, `Block sites from setting any data'.
* Check, `Block third party cookies from being set'.
* Check, `Clear cookies and other site and plug-in data when I close my browser'.
* Click, `Manage Exceptions...'.
* Add and delete hostname patterns until you see what you like.

The problem is, it gives no subdomain examples. Per one bug report, the user cannot figure out the right syntax to enter them. Without adding the right subdomains, navigating to blogger.com mysteriously redirects us in a loop.

Its unusual wildcard syntax, for Google blogging, is:

[*.]blogger.com
[*.]google.com

The brackets must be entered explicitly. In other words, they do not merely indicate optional content.

Some kind of, `"Learn more" about the pattern syntax' link would be awesome.

Explicitly also, one could enter all the relevant subdomains (which is appropriate for some domains):

blogger.com
www.blogger.com
markdblackwell.blogspot.com
google.com
accounts.google.com

Copyright (c) 2011 Mark D. Blackwell.