I'm trying to figure out what is the advantage of Node.JS event-loop mechanism (publish and subscribe to C++ ThreadPool) over the way IIS is handling requests.
I've read here: http://rickgaribay.net/archive/2012/01/28/node-is-not-single-threaded.aspx and the line: "There is no context switching as the Event Loop simply publishes and subscribes to the thread pool." is not clear to me.
IIS has an I/O thread that send the request to the CLR Thread pool, and it continues with the work until it receives a response. Kind of similar to the event loop from what i've understood. The CPU is switching between threads, so it switches to the worker threads of node (in order to get the work done) and same-same as the CLR Thread pool.
Can someone please explain what is the key advantage of the event-loop mechanism over the request threading that IIS uses ?
I think the author you link to adds more confusion than clarity (the guy says he is just learning node, so you're really asking for a blind-leading-the-blind situation in using it to learn from). I don't know why he thinks that Node claims "it" (i.e. Node.js) is single threaded. I have never seen that. The point is that within Node your code all executes in a single thread which means you the developer are freed from dealing with contention of different sorts. (Many people see this as a key advantage, but I think one could argue that you are simply trading one kind of boilerplate (for semaphores or the like) for another: the handling of asynchrony (although several approaches exist for reducing the more tedious aspects of this).
Although I'm not really certain what you are asking, I think if you watch this video (https://www.youtube.com/watch?v=L0pjVcIsU6A) between the 3 minute and 7 minute marks, you will have an "oh, I get it" moment. The visual representation the presenter uses (which I believe he takes in part from a preso by the original Node creator) is far easier to understand than the wall of text which would describe the same thing using words alone.
Hope this helps.