5

I am considering entire JS environment in two different parts in the question.

  1. JS engine
  2. Browser API, Node API (External to JS engine).

JavaScript engines(V8, SpiderMonkey) are single threaded and prior to ES6 there was no mechanism to run async code in JavaScript until ES6 introduced Promise concept.

I understand before promises came in, browsers or Node API(Server side JS) used to provide mechanism to run the code asynchronously using setTimeout and Process.nextTick and since Promises are natively supported to run async code in Javascript, I am trying to understand how promise callbacks and setTimeout are scheduled to run one before another.

Does this mean there are two event loops exists and they coordinate with each other? first in Browser/Node API to run code from setTimeout and Process.nextTick and another in JS engines to run promise callbacks, if no then how they are scheduled as there is no presence of setTimeout and Process.nextTick definition inside JS engines but Promise definition must be present in JS engines as Promise is ES6 standard.

Also I want to understand where is the task queue, job queue, mircotasks are present and managed, Inside JS engines or outside engine(in browsers or Node API).

Akshay Naik
  • 669
  • 1
  • 6
  • 22
  • 4
    ***prior to ES6 there was no mechanism to run async code in JavaScript until ES6 introduced Promise concept*** - This is not correct at all. There was plenty of async code in ES5 and before. Heck, even `setTimeout()` is asynchronous which has been in Javascript from day one. Browsers have had async `XMLHttpRequest`, node.js has whole file system async I/O, etc... – jfriend00 Mar 15 '18 at 06:21
  • Might want to read this: [Why setImmediate executes before fs.readfile in node.js](https://stackoverflow.com/questions/47724811/why-setimmediate-execute-before-fs-readfile-in-nodejs-event-loops-works/47727402#47727402) for lots of detail about the node.js event system. – jfriend00 Mar 15 '18 at 06:25
  • @jfriend00, I believe SetTimeout and XMLHttpRequests are provided by browser API to run code in async, they are not present in JS engines. ref : https://javascript.info/settimeout-setinterval – Akshay Naik Mar 15 '18 at 06:32
  • What you seem to not understand is that promises are merely tools for monitoring asynchronous operations. The underlying operation needs to be asynchronous on its own and really a promise is nothing more than a special kind of event emitter that has a bunch of conventions around reporting completion or error of an async operation. The operations must be asynchronous on their own and then they can be monitored with promises. Promises even existed as add-on libraries that work with older versions of Javascript before ES6. Lots of async operations existed before ES6 and promises. – jfriend00 Mar 15 '18 at 06:53
  • The behavior of many things that use the event loop is specified in the Javascript specification. The actual event loop is typically part of the host environment and is native code that isn't the actual JS interpreter, but the two are heavily connected and the JS interpreter uses the event loop. All asynchronous operations work by using some native code to insert something into the event queue when their operation has completed. The event queue itself is not directly accessible from Javascript. – jfriend00 Mar 15 '18 at 06:56
  • If you look at the answer I referenced in my second comment here, you will see that there are numerous different queues that are all part of the event system and there are various rules and priorities for how they work. Promises use one of those queues for scheduling `.then()` handlers. Other async operations use different queues. – jfriend00 Mar 15 '18 at 06:59
  • Promises in ES6, use "jobs" to schedule `.then()` or `.catch()` handlers to run when they are resolved or rejected. You can read about them here: http://www.ecma-international.org/ecma-262/6.0/#sec-jobs-and-job-queues – jfriend00 Mar 15 '18 at 07:05
  • So does it mean promises callbacks are also scheduled by host environment and only executed by JS engines. – Akshay Naik Mar 15 '18 at 07:07
  • 1
    As far as I know, this all goes through the event system and the event system is implemented separately by each host environment. For example, while Chrome and node.js each use the V8 Javascript engine, Chrome and node.js have separate event systems. To run a Javascript interpreter, the host environment MUST provide an event system. – jfriend00 Mar 15 '18 at 07:20
  • The note in the link says. Typically an ECMAScript implementation will have its Job Queues pre-initialized with at least one PendingJob and one of those Jobs will be the first to be executed. It makes me think job queues are present in Engine to execute promise callbacks. – Akshay Naik Mar 15 '18 at 07:22
  • I agree to event system implementation. Thanks – Akshay Naik Mar 15 '18 at 07:24
  • http://voidcanvas.com/setimmediate-vs-nexttick-vs-settimeout/ – Jack Mar 15 '18 at 09:43
  • Promises have a separate microtask queue which have higher priority compared to the event queue. [Here is a very good read on this particular topic](https://jakearchibald.com/2015/tasks-microtasks-queues-and-schedules/) – Redu Mar 15 '18 at 11:13
  • @jfriend00 it will be nice if you write an answer to this question by summarizing your comments – Akshay Naik Aug 11 '19 at 18:40

1 Answers1

3

the main two js runtime engine:

  • browser
  • nodejs(V8)

in the browser(google browser):

javascript event-loop in browser

MacroTask:

  • setTimeout
  • setInterval

MicroTask:

  • Promise

execution sequence：

Promise> Promise.then> setTimeout

in nodejs runtime:

nodejs event-loop

microtasks:

  • process.nextTick
  • promise

macrotasks:

  • setTimeout
  • setInterval
  • setImmediate
  • I/O

execution sequence：

promise> process.nextTick> promise.then > setImmediate> setTimeout

lots of articles about event-loop. give you some refs to help you know about the theory：

hui
  • 591
  • 7
  • 22