Do they run on the same thread as the node process or do they run on a different thread? The CPU usage for my node process goes above 100% when I do a lot of sets and gets (and add several event listeners) on firebase. Any ideas why?
There is only 1 main thread in your Node application, all of your code and all library javascript code will run in this thread. When a library attempts to use IO, it may call upon libuv which runs in its own thread. Libraries may also have their own C++ bindings. Without knowing what you're doing and how the 3rd party library is implemented, it's impossible to tell.
Related
I have a node process that runs tasks. When I run an intensive task, in top it can show more than 100% CPU usage (around 110%). From some research that I was doing, I figured that nodejs was single-threaded meaning it would only be running on one CPU per process.
Is it possible that the workload could take up the whole CPU so it moves some of the load to another CPU? Was unable to find a clear answer on this.
Other than specifically coding with WorkerThreads (which it doesn't sound like you are using), nodejs runs your Javascript code in only a single thread (e.g. the interpreter itself just uses one thread to run Javascript opcodes).
But, nodejs does have other threads that are used in the implementation of library functions such as file system operations and crypto operations and for the garbage collector. And, some 3rd party libraries may use native threads in their own implementation. So, it is definitely possible for nodejs to use more than just one core. It really depends upon what the code/task is doing and what library functions are being called.
Is it possible that the workload could take up the whole CPU so it moves some of the load to another CPU?
It does not move the running of your Javascript to another CPU. But as I said above, some library functions that use native code may use additional threads.
I've been struggling with this concept:
You can run rust programs in nodejs.
So we all know rust is fast and can handle concurency well and has static memory management and etc...
So maybe I am dumb to understand this concept. Nodejs is a single thread. And everything is running in a event loop.
So how this is working if we have a program that wrote in rust and has multi proccess involing and etc...
What is the behavior of nodejs if we run the program inside the nodejs?
NodeJs' addon API (N-API) is documented here. From the section Asynchronous thread-safe function calls:
JavaScript functions can normally only be called from a native addon's main thread. If an addon creates additional threads, then N-API functions that require a napi_env, napi_value, or napi_ref must not be called from those threads.
When an addon has additional threads and JavaScript functions need to be invoked based on the processing completed by those threads, those threads must communicate with the addon's main thread so that the main thread can invoke the JavaScript function on their behalf. The thread-safe function APIs provide an easy way to do this.
So most calls aren't safe from non-addon-main threads (basically anything affecting the Javascript runtime) though a few calls are dedicated for helping with that.
I have a question, Node.js uses libuv inside of u core, to manage its event loop and by default works whit 4 threads and process queue whit limit of 1024 process.
Process queue limit
Threads by default
So, because most programmers say it's single thread?
By default, node.js only uses ONE thread to run your Javascript. Thus your Javascript runs as single threaded. No two pieces of your Javascript are ever running at the same time. This is a critical design element in Javascript and is why it does not generally have concurrency problems with access to shared variables.
The event driven system works by doing this:
Fetch event from event queue.
Run the Javascript callback associated with the event.
Run that Javascript until it returns control back to the system.
Fetch the next event from the event queue and go back to step 2.
If no event in the event queue, go to sleep until an event is added to the queue, then go to step 1.
In this way, you can see that a given piece of Javascript runs until it returns control back to the system and then, and only then, can another piece of Javascript run. That's where the notion of "single threaded" comes from. One piece of Javascript running at a time. It vastly simplifies concurrency issues and, when combined with the non-blocking I/O model, it makes a very efficient system, even when lots of operations are "in flight" (though only one is actually running at a time).
Yes, node.js has some threads inside of libuv that are used for things like implementing file system access. But those are only for native code inside the library and do NOT make your Javascript multi-threaded in any way.
Now, recent versions of node.js do have Worker Threads which allow you to actually run multiple threads of Javascript, but each thread is a very separate environment and you must communicate with other threads via messages without the direct sharing of variables. This is relatively new to nodejs version 10.5 (though it's similar in concept to WebWorkers in the browser. These Worker Threads are not used at all unless you specifically engage them with custom programming designed to take advantage of them and live within their specific rules of operation.
many question on stackoverflow and others website , some ones says NodeJS is Singlethread and someone says NodeJS is Multithread, and they have there own logic to be Singlethread or Multithread. But If a interviewer ask same question. what should I say. I am getting confusion here.
The main event loop in NodeJs is single-threaded but most of the I/O works run on separate threads.
You can make it multi-threaded by creating child processes.
There is a npm module napajs to create a multi-threaded javascript runtime.
However,the 10.5.0 release has announced multithreading in Node.js. The feature is still experimental and likely to undergo extensive changes, but it does show the direction in which NodeJs is heading.
So stay tuned!!
NodeJS runs JavaScript in a single threaded environment. You get to use a single thread (barring the worker_threads module, and spawning processes).
Under the scenes, NodeJS uses libuv, which uses OS threads for the async I/O you get in the form of the event loop.
I am writing a client in C# that is communicating with a Windows C++ DLL that uses boost asio asynchronous calls. I have read before that ASIO does not work too well in a managed environment. The VC++ DLL is an unmanaged project that creates an unmanaged thread for the I/O handlers. The C# code creates a background thread to handle sending messages to the C++ DLL via pinvoke. My question is - can the call to the boost::asio::async_write method be on a managed thread? Or, does it have to be on an unmanaged thread?
It will help simplify the logic and processing if I can make the call to async_write on the managed thread. But, I'm worried about what might happen when the .NET garbage collector runs and stops the threads. I don't know if ASIO will be able to handle that or not. I'm not passing any pointers to data defined in the C# code, so that should not be a problem.
The notion of a "managed thread" is a weak one, the operating system only supports one kind of thread. A thread that runs managed code isn't special, managed code gets translated to the exact same kind of machine code that a C compiler generates. The only difference is that the CLR knows about the thread and will have a reason to have a look at its stack when a garbage collection occurs. Necessary to find stack frames of managed code that may contain object references.
It will not be interested in any stack frames that belong to native code, it simply ignores them. And yes, the thread may be paused while the GC performs the search but only if it is currently executing managed code. Native code keeps running, it will only block when it returns back to a managed method if a GC is in progress. This pause isn't otherwise different from any other kind of reason a thread may pause, including losing the processor for a while when the operating system scheduler runs something else.
So using boost::asio is fine, nothing goes wrong. Just as the many other ways that a managed program can execute native code, including operating system calls. The only detail you'll want to take care of is making sure that your code gets compiled without /clr in effect. Compiling boost code to IL works fine, it just isn't very efficient.