This site is about programming(mostly) things I either do or am learning.
“I am the coolest of all time!” (probably said by “The Fonz” )
I went to the libuv website which is a support library written for node.js. You will eventually end up there when researching the node.js event loop. It has to do with the event loop and things like that. I was wowed when I saw their logo…just too cool.
In event-driven programming, an application expresses interest in certain events and respond to them when they occur. The responsibility of gathering events from the operating system or monitoring other sources of events is handled by libuv, and the user can register callbacks to be invoked when an event occurs. The event-loop usually keeps running forever. In pseudocode:
while there are still events to process: e = get the next event if there is a callback associated with e: call the callback
Some examples of events are:
Node automatically starts the event loop of libuv
A common activity of computers is to deal with Input/Output(versus some kind of number crunching) and these take a lot of time. These functions are blocking meaning no other processing can happen while this task is being worked on. Many systems handle this by using threads whereby each operation is started or allocated to its own thread or threadpool. This enables the CPU to work on other things.
LIBUV uses another solution..the asynchronous non-blocking approach. Operating systems have event notification built in. For example, a normal read call on a socket would block until the sender actually sent something. Instead, the application can request the operating system to watch the socket and put an event notification in the queue. The application can inspect the events at its convenience (perhaps doing some number crunching before to use the processor to the maximum) and grab the data.
It is asynchronous because the application expressed interest at one point, then used the data at another point (in time and space). It is non-blocking because the application process was free to do other tasks. This fits in well with libuv’s event-loop approach, since the operating system events can be treated as just another libuv event. The non-blocking ensures that other events can continue to be handled as fast as they come in.
LIBUV and OSes will usually run a background/worker thread and or/polling to perform tasks in a non-blocking manner. A default-loop is provided by LUBUV and this is the loop that NODEJS uses as its mail loop.
LIBUV hands off to O/S
Certain tasks are not even done in the event loop. Most networking type tasks(making/receiving requests, setting up a listener on a port) are handed off to the operating system which knows how to handle things like network requests. The operating system decides where and how to run this tasks with its own threads. These tasks can originate with our NODEJS app, but they will be taken care of by the particular O/S coordinating thru LIBUV.
I/O read callbacks(such as files/sockets) will return a < 0 flag if there was an error.