When http request hit into the Nodejs application the connect first received by Nodejs main thread (which is js main thread) and passed to event loop, if my understand is correct
The event loop is what allows Nodejs to perform non-blocking I/O operations, JavaScript is single-threaded — by offloading operations to the system kernel whenever possible.
The above statement is from Nodejs official documentation, so my question where does the main thread lives?
out side the event loop or inside the event loop
is both different? Can someone give good pictures how Nodejs work internally, with graphical representation?
Main thread is the execution thread. As asked, it stays outside the event loop and will check for any events pertaining to the event loop.
If the even added to the event loop is synchronous and only needs some CPU operations, the main thread will take control directly and will execute the need.
If an asynchronous event is added to the event loop that is delegated to the worker threads available. Worker threads will perform the async operation(db/API/fs calls). Once the async part of the event is completed the event is again added to the event loop for the execution of the remaining synchronous part.
The worker threads are built over libUV and will spawn according to the main thread requirement. This reason makes Node.js more efficient while handling async calls and less preferred for CPU extensive operations.
Follow this for a more detailed explanation:What function gets put into EventLoop in NodeJs and JS
Related
A Javascript web application has an event loop to handle the call stack and it loops around to check for any task queues returned by the browser's web API to run when the call stack is free. I will use v8 as the example for the javascript engine.
I've always pictured this call-stack as part of the V8 engine, it ultimately executes our Javascript as a synchronous program. Any delegation of multi-threaded action to an API like libuv/libevent must return back to the V8 execution call stack by asynchronous processing.
But recently, I've read chromium and node.js uses the event loop provided from libevent/libuv over the v8 implementation. This part really messes with my mental model a bit. The event loop is the perfect solution to get asynchronous processing when it resides in v8, we wait for API to return a queue to our macro/microtask and execute them by the next loop around priority check.
why do we need to take it out of v8 (as the most diagram shows event loop resides outside of v8)? if the event loop is outside of v8, does that mean v8 is no longer executing the javascript code anymore but instead the outside event loop executing our Javascript program and other codes provided by the respective libraries?
Frankly this is also my first time knowing that event loop component is not part of v8.
But I don’t have issue understanding that we can take it out of v8. I know I’m not authoritative but here’s me sharing my understanding with you:
Your previous mind model goes like, v8 actively busy loops to check over signal of continuation.
In the new model, that responsibility is just shift over to libuv, v8 registers a callback to libuv, saying that “I’m waiting for signal of a certain file/network/timeout IO interrupt, call me back when it happens”, and then v8 goes to sleep, leaving libuv busy looping.
When that signal arrives, libuv callbacks to v8 to wake it up, and v8 continues to execute JS tasks. So not, libuv doesn’t execute JavaScript, it’s still v8.
The only thing changed is where to put the looping code. This is just a matter of where to draw the boundary between software components.
Are there any example situations which can clarify about the selection of synchronous vs asynchronous selection of coding.
Is synchronous code always bad choice over asynchronous code while writing high-performance service in Node.js?
Yes, see this guide in the Node.js documentation for details. Here are a couple of relevant quotes from it:
Here's a good rule of thumb for keeping your Node server speedy: Node is fast when the work associated with each client at any given time is "small".
This applies to callbacks on the Event Loop and tasks on the Worker Pool.
(their emphasis)
And:
Why should I avoid blocking the Event Loop and the Worker Pool?
Node uses a small number of threads to handle many clients. In Node there are two types of threads: one Event Loop (aka the main loop, main thread, event thread, etc.), and a pool of k Workers in a Worker Pool (aka the threadpool).
If a thread is taking a long time to execute a callback (Event Loop) or a task (Worker), we call it "blocked". While a thread is blocked working on behalf of one client, it cannot handle requests from any other clients. This provides two motivations for blocking neither the Event Loop nor the Worker Pool:
Performance: If you regularly perform heavyweight activity on either type of thread, the throughput (requests/second) of your server will suffer.
Security: If it is possible that for certain input one of your threads might block, a malicious client could submit this "evil input", make your threads block, and keep them from working on other clients. This would be a Denial of Service attack.
Please also check this discussion -
https://www.quora.com/Is-synchronous-code-always-bad-choice-over-asynchronous-code-while-writing-high-performance-service-in-Node-js
In a tutorial I've read that one should you Node's event-loop approach mainly for I/O intensive tasks. Like reading from hard disk or using network. But not for CPU-intensive task.
What's the concrete reason for the quoted statements?
Or the otherwayaround asked:
What would happen if you occupy Node.js with CPU-intesive tasks to do?
Node uses a small number of threads to handle many clients. In Node there are two types of threads: one Event Loop (aka the main loop, main thread, event thread, etc.), and a pool of k Workers in a Worker Pool (aka the threadpool).
If a thread is taking a long time to execute a callback (Event Loop) or a task (Worker), we call it "blocked". While a thread is blocked working on behalf of one client, it cannot handle requests from any other clients.
You can read more about it in official nodejs guide
The general perception is that JavaScript is intrinsically single-threaded but it can run asynchronously. I wonder how a single-threaded model like this handles AJAX requests that are non-blocking?
Lets say a non-blocking AJAX request is fired in a browser, but doesn't get a response immediately. If the event loop keeps checking for the response, doesn't the execution get blocked? Does the event loop keeps checking for its status and 're-adding' the task to the back of the macrotask queue when there is no response?
From what I understand, Node.js does silently spawn threads to handle I/O operations accessing disks, databases, network sockets etc. Does JavaScript in browsers spawn threads to handle AJAX too?
A similar question could be asked about the following:
var img = new Image();
img.onerror=function(){alert('error: '+this.src);}
img.onload=function(){alert('image loaded: '+this.src);}
img.src='path/to/image.jpg';
Does the last line of code above causes an additional thread to be spawned, because the statement seems to be non-blocking?
The general perception is that JavaScript is intrinsically single-threaded but it can run asynchronously.
It's true that JavaScript is specified¹ such that only a single thread can be executing within a realm at any given time. (A realm is the global environment and its associated objects; e.g. a window/tab [on browsers].) You can have multiple active threads (in different windows, or via web workers), and they can talk to each other (via postMessage) or even share some memory (SharedArrayBuffer), but they can't access the same realm at the same time. Keeping realms effectively single-threaded avoids a huge range of concurrent programming pitfalls.
I wonder how a single-threaded model like this handles AJAX requests that are non-blocking?
JavaScript allowing only one thread within the JavaScript environment at a time doesn't mean that the host (the browser) is single-threaded. An asynchronous ajax request is handed off to the browser's network handling.
JavaScript works on the basis of a job queue (the HTML5 speec calls it a task queue, but the JavaScript spec speaks of "jobs" — it's just a name). The JavaScript thread picks up a job from the queue, runs that job to completion, and then picks up the next job, if any. (It's a bit more complicated than that, but that's the basic idea.) While the thread is running a job, no other thread can run another job in the same realm.
So when an ajax request completes (success, timeout, whatever), the browser (on a non-JavaScript thread, probably) puts a job in the JavaScript job queue to call the ajax callback. The JavaScript thread picks up that job and calls the callback.
It's worth noting that that is also exactly what it does in response to other things that happen, such as the user clicking something.
Lets say a non-blocking AJAX request is fired in a browser, but doesn't get a response immediately. If the event loop keeps checking for the response, doesn't the execution get blocked?
The key is that the thread doesn't continually check back for a response. The thread just watches the job queue. The browser's network handler handles completion of network requests.
¹ This was made explicit in ES2015, but it was the case for common environments (browsers, Node.js) for years prior to that. There were JavaScript environments that allowed multiple threads in a realm (like Rhino, running JavaScript on the Java VM), but they weren't considered important enough to prevent ES2015 adding this requirement, and doing so allowed defining precise semantics around several new features that would have been much more complicated to specify, if it was even possible, while remaining silent on the subject of threading.
lets talk about JavaScript code which has setInterval methods every 2 sec.
I also have a onblur animation event for some control.
In a case where onblur occurs (+ animation), I might get the setInterval function.
Question:
Does async programming mean multi-threading? (in any way?)
No. It means literally what it means-- asynchronous. Understanding the difference between asynchronous programming and thread-based programming is critical to your success as a programmer.
In a traditional, non-threaded environment, when a function must wait on an external event (such as a network event, a keyboard or mouse event, or even a clock event), the program must wait until that event happens.
In a multi-threaded environment, many individual threads of programming are running at the same time. (Depending upon the number of CPUs and the support of the operating system, this may be literally true, or it may be an illusion created by sophisticated scheduling algorithms). For this reason, multi-threaded environments are difficult and involve issues of threads locking each other's memory to prevent them from overrunning one another.
In an asychronous environment, a single process thread runs all the time, but it may, for event-driven reasons (and that is the key), switch from one function to another. When an event happens, and when the currently running process hits a point at which it must wait for another event, the javascript core then scans its list of events and delivers the next one, in a (formally) indeterminate (but probably deterministic) order, to the event manager.
For this reason, event-driven, asynchronous programming avoids many of the pitfalls of traditional, multi-threaded programming, such as memory contention issues. There may still be race conditions, as the order in which events are handled is not up to you, but they're rare and easier to manage. On the other hand, because the event handler does not deliver events until the currently running function hits an idle spot, some functions can starve the rest of the programming. This happens in Node.js, for example, when people foolishly do lots of heavy math in the server-- that's best shoved into a little server that node then "waits" to deliver the answer. Node.js is a great little switchboard for events, but anything that takes longer than 100 milliseconds should be handled in a client/server way.
In the browser environment, DOM events are treated as automatic event points (they have to be, modifying the DOM delivers a lot of events), but even there badly-written Javascript can starve the core, which is why both Firefox and Chrome have these "This script is has stopped responding" interrupt handlers.
A single threaded event loop is a good example of being asynchronous in a single threaded language.
The concept here is that you attach doLater callback handlers to the eventLoop. Then the eventLoop is just a while(true) that checks whether the specific timestamp for each doLater handler is met, and if so it calls the handler.
For those interested, here is a naive (and horribly inefficient toy) implementation of a single threaded event loop in JavaScript
This does mean that without any kind of OS thread scheduler access of your single thread, your forced to busy wait on the doLater callbacks.
If you have a sleep call you could just do sleep until the next doLater handler which is more efficient then a busy wait since you deschedule your single thread and let the OS do other things.
No asynchronous programming doesn't mean multithreading specifically.
For achieving multiple tasks at the same time we use multi-threading and other is event loop architecture in node js.
JavaScript is synchronous and single threaded and that is why node js is also single threaded but with event loop node do a non-blocking I/O operations. Node.js uses the libuv library that uses a fixed-sized thread pool that handles the execution of parallel tasks.
Thread is a sequence of code instructions and also the sub unit of process.
In multi-threading, processes have multiple threads.
In single threading, processes have single thread.
Only in the sense that it executes code haphazardly and risks race conditions. You will not get any performance benefits from using timeouts and intervals.
However, HTML5's WebWorkers do allow for real multithreading in the browser:
http://www.html5rocks.com/en/tutorials/workers/basics/
If there is a callback, something has to call it. The units of execution are threads & so, yes, some other thread has to call the callback, either directly or by queueing up some asynchronous procedure call to the initiating thread.