when we call setTimeout(func, millSec) does the program stop executing for a specified millisecond or It keep executing normally and simply call the function after the specified time.
Simple definition
setTimeout() schedules a function to be run after a minimum threshold in ms has elapsed. Timing will be bound by the performance of the process (which can be impacted by other applications running on the machine).
when we call setTimeout(func, millSec) does the program stop executing
for a specified millisecond
No, It put that function into the stack and run Timer and pick next task
Source
There is a concept of Events which emit the event when the task is completed and then that function put into the Event loop if Call Stack is clear then the task is process from Event loop and put into Call Stack to execute
Source - freecodecamp
and simply call the function after the specified time.
Yes, it calls once its push from Event loop to Call Stack, But Timing will be bound by the performance of the process (which can be impacted by other applications running on the machine).
Useful links
https://nodejs.org/en/docs/guides/timers-in-node/
https://nodejs.org/en/docs/guides/event-loop-timers-and-nexttick/
The Timers module in Node.js contains functions that execute code after a set period of time. Timers do not need to be imported via require(), since all the methods are available globally to emulate the browser JavaScript API. To fully understand when timer functions will be executed, it's a good idea to read up on the the Node.js Event Loop.
Related
I’ve recently started to figure out what event loop really is and that confused me a lot, seems like I don’t know how nodejs works..
I mean when program starts, gets loaded into memory - what’s next?
I can’t see a place inside event loop where all sync. Code executes (like for/ while cycles that’s computes something).. doesn’t that means that V8 executes JavaScript and starts event loop when needed?
If anybody can help and explain how nodejs runtime is functioning on the high level would be really great
I highly recommend reading this Asynchrony: Now & Later
and I'll quote some things that I've once read.
........
JS Engine know nothing about code being asynchronous,It only execute code at a time and finishes..no more no less
the JS host environment is the one who has an implementation of the event-loop concept where code that doesn't need to run now(in the future),is waiting(imagine a network call/ io call) to finish processing and get called (be added to the event-queue of the event-loop and then executed at a next tick)
At program start,I'm 100% sure but I think all code is added to the event-queue(the way how the event-loop is implemented) and it's processed as First in First out (FIFO) which means the earlier the code the first is executed,and while running if some code need to be stalled like a setTimeout or IO process or an Ajax call(which both need time) it's up to them to use for example a callback to call(here the callback is added to the event-queue) and it's the event-loop responsibility to execute these callback in order that they've reached in at a next future tick.
I'm pretty new to node and am trying to setup an express server. The server will handle various requests and if any of them fail call a common failure function that will send e-mail. If I was doing this in something like Java I'd likely use something like a synchronized block and a boolean to allow the first entrance into the code to send the mail.
Is there anything like a synchronized block in Node? I believe node is single threaded and has a few helper threads to handle asyncronous/callback code. Is it at all possible that the same line of code could run at exactly the same time in Node?
Thanks!
Can the same line of Node.js code run at the same time? Is it at all possible that the same line of code could run at exactly the same time in Node?
No, it is not. Your Javascript in node.js is entirely single threaded. An event is pulled from the event queue. That calls a callback associated with that event. That callback runs until it returns. No other events can be processed until that first one returns. When it returns, the interpreter pulls the next event from the event queue and then calls the callback associated with it.
This does not mean that there are not concurrency issues in node.js. There can be, but it is caused not by code running at the same physical time and creating conflicting access to shared variables (like can happen in threaded languages like Java). Concurrency issues can be caused by the asynchronous nature of I/O in node.js. In the asynchronous case, you call an asynchronous function, pass it a callback (or expect a promise in return). Your code then continues on and returns to the interpreter. Some time later an event will occur inside of node.js native code that will add something to the event queue. When the interpreter is free from running other Javascript, it will process that event and then call your callback which will cause more of your code to run.
While all this is "in process", other events are free to run and other parts of your Javascript can run. So, the exposure to concurrency issues comes, not from simultaneous running of two pieces of code, but from one piece of your code running while another piece of your code is waiting for a callback to occur. Both pieces of code are "in process". They are not "running" at the same time, but both operations are waiting from something else to occur in order to complete. If these two operations access variables in ways that can conflict with each other, then you can have a concurrency issue in Javascript. Because none of this is pre-emptive (like threads in Java), it's all very predictable and is much easier to design for.
Is there anything like a synchronized block in Node?
No, there is not. It is simply not needed in your Javascript code. If you wanted to protect something from some other asynchronous operation modifying it while your own asynchronous operation was waiting to complete, you can use simple flags or variables in your code. Because there's no preemption, a simple flag will work just fine.
I believe node is single threaded and has a few helper threads to handle asyncronous/callback code.
Node.js runs your Javascript as single threaded. Internally in its own native code, it does use threads in order to do its work. For example, the asynchronous file system access code internal to node.js uses threads for disk I/O. But these threads are only internal and the result of these threads is not to call Javascript directly, but to insert events in the event queue and all your Javascript is serialized through the event queue. Pull event from event queue, run callback associated with the event. Wait for that callback to return. Pull next event from the event queue, repeat...
The server will handle various requests and if any of them fail call a common failure function that will send e-mail. If I was doing this in something like Java I'd likely use something like a synchronized block and a boolean to allow the first entrance into the code to send the mail.
We'd really have to see what your code looks like to understand what exact problem you're trying to solve. I'd guess that you can just use a simple boolean (regular variable) in node.js, but we'd have to see your code to really understand what you're doing.
Does process_child.spawn() start the process immediately, or does it wait until the current execution context clears the stack?
The docs say that "spawn ... follows the idiomatic asynchronous programming pattern typical of other Node.js APIs."
Does that imply that process execution is deferred as a callback queue event, to be picked up by the event loop after the spawn() caller's execution context clears the stack?
My concern is that the spawned process could trigger events (eg, write to stdout) before my code has had a chance to install a handler for them. And it seems I'm not the only one with this concern: https://github.com/nodejs/node-v0.x-archive/issues/4030#issuecomment-315392492
The docs say that "spawn ... follows the idiomatic asynchronous programming pattern typical of other Node.js APIs."
Does that imply that process execution is deferred as a callback queue event, to be picked up by the event loop after the spawn() caller's execution context clears the stack?
No. It does not imply that. The idiomatic asynchronous programming pattern is to initiate the asynchronous operation in the current tick and then once it is started and being executed or controlled by other means, then control is returned back to Javascript. Future events will communicate its status or result at that point. The same is true of other typical asynchronous operation such as file I/O or network I/O.
As with most async APIs, it calls the OS synchronously to tell it to launch the other app and then exactly how much work towards actually starting the other process gets done before it returns control back to your JS depends upon the OS and internals of the implementation on a specific OS. To know more specifically exactly what it waits for before returning, you'd have to examine the native code source code for your particular platform and then you'd have to delve into what the OS calls that it's using do on your platform.
The general model is that the asynchronous operation is initiated and then it returns control back to your JS. Since what is going on in this async operation is the launching of a new process and the OS takes care of the real work in another process, there wouldn't be any reason for node.js to postpone actually calling the OS until a future tick of the event loop. You can't get any events from the the new process until a future tick of the event loop anyway because those events all go through the event queue.
Working through the node.js source code, it gets to here in the source code where it calls uv_spawn() in libuv (the cross platform library node.js is built on). It looks to me like everything has been synchronous up to this point (no waiting for next tick). Next step is to look into libuv code to see what uv_spawn() does.
It is interesting to note when following the source code that exceptions or synchronous errors are caught internally and emitted as events on future ticks (not synchronously). This allows you to get the child_process object returned from the function back from the spawn() call, install event handlers on it and not miss any events.
uv_spawn() source code is here and it appears to make an OS call to fork() on the same tick.
TLDR
So, I see no evidence of any purposeful postponing the actual OS call to start the new process to a future tick. It appears to call the OS on the same tick. There is evidence of postponing error reporting to a future tick to simplify use of the interface.
To your additional point you added, the streams that receive stdio and stdout are set up before the new process is started. Since they will receive data from the new process via the JS event queue, as long as you set up your own event handlers on those streams in the same tick that you call spawn() (e.g. not in some async callback), then those event handlers will be installed before any data can be received and notified on the stdio and stdout streams. This is a product of the single-threaded, event driven nature of node.js Javascript.
I have an issue with a timer function not always running as desired in Matlab.
I am trying to run an external simulation then fire a watcher function which checks the sim has exited correctly after a set time, if not it will force kill the task so it can be started again.
However the function works correctly for the first 2 batches of simulations then ceases to run. I am restarting the timer and using single shot. So each time the sim exits the timer is restarted. The timer callback is the function to kill the sim and the docs say 'Callback functions execute code during some event' which suggests the function should run regardless of any other matlab code. Is this correct or do callbacks work in some other way?
I initially thought this to be an issue with the execution queue holding the matlab worker for the sim, however it doesn't explain why it works for the first 100 or so times.
To be able to solve my issue I need more information on how the matlab workers work with regards to timer call backs. I am aware that unless specified matlab works on a single execution queue but I do not understand how callbacks function in this environment.
Any information regarding when and how timer call backs execute (ie do they fire exactly when timed to do so or do they simply get added to the queue at that time?) and any way of forcing a function to run regardless of the current worker would be greatly appreciated.
I have tried using batch() instead of a timer call back but the shell commands do not seem to work in a batch function (I have no idea why).
Many thanks
I am trying to write a Node.js program to execute and monitor javascript programs. I am looking for a way to find out whether the monitored program is still "running" i.e. doing anything useful.
In my current approach, when receiving code to test, I start a new child process and hand the code to it. The child process instruments the code creates a Sandbox using Contextify and executes the code using this sandbox.
After the sandbox.run(code) call returned I know that the blocking part of the code finished and can show that in the UI. However, I don't now whether the code registered any timers using setTimeouts or created any other event sources that would cause parts of the code to be exited later. So I don't know whether it's really "finished" yet.
Is there a way in Node.js to check whether there are still events on the event loop to be handled (or even better, how many are left)?
I found this other question, but it only talks about how to monitor the event loop to find out whether the performance of node is still fine. But I'm not interested in the performance (I don't care if the executing code is blocking for 10s or only doing something for 1ms every 2 minutes) and I don't want to use outside tools but find out about the state of the event loop from inside node itself. Is that possible?
I solved my problem in a way, although I didn't find a general answer to the question.
The idea here is that the process will exit by itself if it has executed all the code it was started with and no EventEmitters are registered anymore. This was basically what I wanted, since I wanted to be notified when the process was "done" and now I could just listen to the "exit" event of the child_process.
But my process that executed the code didn't exit by itself. This had two reasons:
I used a timer to regularly send the data gathered about the execution to the parent process. If such a timer is registered the process won't exit. You could unref the timer but I was afraid that would lead to data loss since the process could quit before the last bit of data was sent out (since it wouldn't wait for the timer to execute). So I changed my code to only schedule a timer if there was data to be sent out instead of regularly checking for data to be sent.
I used fork to create the child process. This also creates a communication channel between the parent and child process and since I needed to send the code to execute to the child_process I registered the child process for messages received from the parent using process.on("message", callback). However, now we have another EventEmitter registered which prevents the process from quitting. Luckily, I realized that I only needed one message from the parent process and no further messages so I could remove the event emitter after receiving that message. So instead of process.on() I used process.once() which will execute the callback only once and automatically remove the event emitter after that. Exactly what I wanted. Alternatively you could use process.removeListener().
Now I just wait for the child_process to exit and thus know that everything is finished and can notify the client.
So the solution here is to make sure none of your own EventEmitters keep the process alive and then just wait for it to exit.