4 ms·
>sometimes be async and sometimes resolve in the same tick That's still asynchronous though isn't it? (Correct me if I'm wrong I'm just spitballing, still lear
by dvdcxn 11y ago
>sometimes be async and sometimes resolve in the same tick
That's still asynchronous though isn't it? (Correct me if I'm wrong I'm just spitballing, still learning).
There's no lower bound on the minimum amount of ticks a process can take for it to be async. What gives it that async-ness is that the upper bound is unknown, indeterminate, and changeable.
Ergo, if some process is sometimes synchronous, and sometimes asynchronous, it's really a process that is asynchronous, but just so happens to occasionally execute in synchronous-like time.
- wonnage 11y agoThe meaning of 'tick' here is special, since we're talking about Node. It's not a measure of time, it's an iteration of Node's event loop. Because Node is single-threaded, everything that happens in a single tick (i.e, one run of the event loop) is in the same execution context/stack/call tree/whatever you want to call it. So we generally call this "synchronous", although technically you could be holding onto the tick forever, firing off a bunch of nonblocking IO in there and doing your own polling/event management. Of course, that would be silly, since Node manages an event loop for you. So your nonblocking IO would instead push events onto the queue, and let Node move on to the next tick. If something happens in a different tick, it gets its own clean slate of an execution context, and we call this "async", since the function that triggered it is no longer running.
- dvdcxn 11y agoThat makes a lit of sense, thanks for the explanation.