How do I shoot an event EXACTLY after given time in milliseconds? Is there any module for that? I was looking for it on google, but didn't find anything satisfactory...
You can't control exact execution of code in the Event Loop. If you need this, then you should look at using a different Framework/Language.
Understanding the Node.js Event Loop, Timers and process.nextTick()
There are no guarantees of when setTimeout() will run, only a guaranteed minimum of how long it will wait, see below excerpt from the above guide:
setTimeout() schedules a script to be run after a minimum threshold in ms has elapsed.
The closest you have is process.nextTick() and even then you're at the mercy of the Event Queue because other things queued with process.nextTick() can occur before yours. This is also dangerous due to possible starvation of the Event Loop if not implemented correctly.
Related
I've been using various concurrency constructs for a while now without much consideration for how all the magic happens, which has recently made me increasingly uneasy.
In an attempt to remedy this ... feeling, I have been reading up on how async works under the hood. When I say async, in this case I'm referring to userland / greenthread / cooperative multitasking, although I assume some of the concepts will also apply to traditional OS managed threads insofar as a scheduler and workers are involved.
I see how a worker can suspend itself and let other workers execute, but at the lowest level in non-blocking library code, how does the scheduler know when a previously suspended worker's job is done and to wake up that worker?
For example if you fire up a worker in some sort of async block and perform an operation that would normally block (e.g. HTTP request, SQL query, other I/O), then even though your calling code is async, that operation (library code) better play nice with your async framework or you've effectively defeated the purpose of using it and blocked your scheduler from calling other waiting operations (the, What Color is Your Function problem) while it waits for your blocking call, which was executed inside your non-blocking calling code, to complete.
So now we've got async code calling other async library code, and now I'm asking myself the question all over again - how does the async library code know when to suspend and resume operation?
The idea of firing off a HTTP request, moving on, and returning later to check for results is weird to think about for me - not conceptually but from an implementation standpoint.
How do you perform a partial operation, e.g. sending TCP packets and then continuing with the rest of the program execution, only to come back later and check if results have been delivered. Delivered to what? A socket?
Now we're another layer deep and you are using socket selects to avoid creating threads and blocking, but, again...
how do those sockets start an operation, move on before completion, and then how does select know when data is available?
Are you continually checking some buffer to see if bytes have been delivered in an infinite loop and moving on if not?
Anyhow - I think you see where I'm going here....
I focused mainly on HTTP as a motivating example, but the same question applies for any normally blocking operations - how does it all work at the bottom?
Here are some of the resources I found helpful while researching the topic and which informed this question:
David Beazley's excellent video Build Your Own Async where he walks you through a simple implementation of a scheduler which fire callbacks and suspend execution by sleeping on a waiting queue. I found this video tremendously instructive, but it stops a bit short in that it shows you how using an async sleep frees up the scheduler to execute other workers, but doesn't really go into what would happen when you call code in those workers that itself must be non-blocking so it plays nice with the scheduler.
How does non-blocking IO work under the hood - This got me further along in my understanding, but still left with a few uncertainties.
I would like to be able to tune the Node event loop to abort or throw an exception if ever a piece of code listening for an event takes too long to execute.
Using the Async Hooks API, it is possible to monitor the time that a callback runs for. However, I cannot find a way to take control in any way.
Ideally I would like to be able to tune Node so that no synchronous code runs for too long. Code running for too long will cause the application to become blocked and unresponsive. (see example). So if I could set a limit to how long any callback is allowed to run for, that would be good.
From my research I think that what I want is not possible, but I would love to be wrong :)
EDIT: Any documentation about what tuning options are available would close this issue. So far I have only heard of garbage collection and heap size.
Node.js is single-threaded by design. For this reason it's not a good choice for CPU-intensive apps in the first place.
It's generally unsafe to interrupt a running thread asynchronously, regardless of the programming language, and JavaScript is no exception. A thread might be in a state when it locked some resources, allocated memory, is modifying global data, etc. so interrupting it can lead to deadlock, memory leaks, data corruption, etc.
A process that can be safely interrupted needs to implement that explicitly, for example by periodically checking for some flag and then stopping in a safe manner. Games often use time-based compute loops in which the elapsed time is checked periodically and the loop exits when it reaches e.g. 20ms, for the process to be continued later during the next invocation.
When possible, break down a long-running computation into a series of shorter steps/callbacks.
Are there explicit considerations about the latency of any single request in the node.js event loop? AFAICT every IO call returns an eventEmitter which emits an event. The processing of all the events is multiplexed through the use of a pipe. So it is possible that the event that needs to be processed for an important request may be placed too far back into the pipe. Is there some sort of priority queue that can be used to schedule the order of execution of eventHandlers ?
Here's why I asked this question in the first place. I decided to give a gist.github link because the reason is long and related to the technical question
It's not clear exactly what you're asking here. Your Javascript does not directly add things to the event queue (that is only done with native code). Instead, you call some async operation and the native code behind that operation adds something to the event queue when the async operation completes.
This article The Node.js Event Loop, Timers, and process.nextTick() gives you a lot of details about how the event queue is serviced and how it handles different types of events (timers, I/O, etc...).
In general things are FIFO (first in, first out) within an event type with some exceptions.
process.nextTick() will run its callback BEFORE waiting I/O events.
setImmediate() will runs its callback AFTER waiting I/O events.
More detail here: setImmediate vs. nextTick and nextTick vs setImmediate, visual explanation and setTimeout vs. setImmediate vs. nextTick
So it is possible that the event that needs to be processed for an important request may be placed too far back into the pipe.
You'd have to show us the specific situation you're concerned about. If you yourself are scheduling a callback with setTimeout(), setImmediate() or process.nextTick(), then you have some control over when it happens by which of these three you pick. If you aren't scheduling it yourself (e.g. it's the completion callback of some async operation), then you don't control it's scheduling in the event loop. It will go into the sub-queue that matches its type and be served FIFO from that phase or the event loop (as described in the above articles).
Is there some sort of priority queue that can be used to schedule the order of execution of eventHandlers ?
There is no exposed priority system. Within an event type, things are FIFO. Again, if you give us an actual coding example so we can see exactly what you're trying to do, we could offer some help on what your choices are. You may be able to use the setTimeout(), setImmediate() and process.nextTick() tools that are already available or you may want to implement your own task queuing and prioritization system that runs off some of the above three methods that allows you to prioritize things that are already queued yourself.
About priorities of execution in the event loop:
setImmediate() runs before setTimeout(fn, 0)
nextTick() triggers the callback on next tick (iteration)
Natively the event loop in node.js does not support priorities. You can always implement your own priority queue or use an existing one like here and assign your functions to the priority queue.
setTimeout in nodejs is implemented with c language library libev ev_timer. How does ev_timer work?
Is it implemented using polling? If I set a timeout of 30 seconds, does any process check for every milliseconds for pending timeouts?
libev has been replaced by libuv.
The timer API is illustrated here
Basically the event loop goes for polling after all other non-IO activities in the system are completed. At the moment, it will have one or more I/O events pending, and one or more timer events, among other things. The input to the poll is crafted in such a way that it's timeout is the least among the registered time events. This, in conjunction with a relative time field which the event loop maintains, helps to figure out the right time for the timer callback to be fired.
In short, the amount of time to wait is delegated to the OS through the poll call, not through regular wake up and recheck.
Hope this helps.
In a typical ASIO or event-based programming library like libevent, is there a way to set a deadline for each callback?
I am worried about possible infinite loops within the callbacks. Is there a way to gracefully detect them, remove the misbehaving callback from task queue and continue processing other tasks in the queue?
I can think of a way to detect it through an external thread and kill the event-loop thread and create a different thread but I am trying to see if there are any other commonly used methods. I believe this is a problem which someone has faced at some point of time and thought through a solution
There is no general way to unstick a thread without its cooperation, whether it's running a callback or not. The thread may hold critical locks or may have acquired resources that would never get released if the thread was somehow coerced to stop from the outside.
If you really do need this functionality, then all code that could potentially be interrupted must be designed to support some specific method of interruption. You can start a deadline timer when you enter the callback and cancel it when you're finished. The deadline timer would have to trigger the thread's interruption mechanism. You'd need at least one other thread running the I/O service in order for some thread to run the timer handler while the callback was running in another thread.
You can also isolate the code in its own process with some kind of wrapper. Then if the code fails to terminate, you can kill the process from the outside.