1

Is it true that the resolve() function and then() function below are the only functions in the ES6 Promise mechanism that look at and add the fulfillment handlers to the job queue (and mark them as already added and never again)?

let promise = new Promise(function(resolve, reject) {
    console.log("resolve, reject are", resolve, reject);
    setTimeout(function() {
      resolve("this is the success data");
    }, 1000);
});

promise.then(
  function(a) { 
    console.log("Success.", a); 
    promise.then(function(a) { console.log("Go have a drink.", a); });
  },
  function(a) { 
    console.log("failure", a) 
  }
);

An alternative to the above code is, the resolve() is done directly, without being in the setTimeout(). Is it true that the then(fn) will add the fn to the fulfillment handler table (not job queue) for this promise, or if the promise has already been resolved, directly add the fn to the job queue, and the fn is marked as "already added to job queue" and no need to be added again?

On the other hand, the resolve() is a JS ES6 provided function, that mark a promise as "resolved" (state), and check if the fulfillment handler table for this promise is empty or not. If there are such handlers (and should not have been marked already added to the job queue before), then these handlers are added to the job queue and marked as already added.

And in any event, suppose there are fn1, fn2, fn3, ... etc in the fulfillment handler table, each one is added to the job queue as fn1(resolvedValue), where the resolvedValue is remembered internally by the resolve(resolveValue) call?

And there are no other situation where the fulfillment handler table is accessed at all. The job queue jobs are executed by the JS event loop, so that when all the GUI "click event handlers", etc are done, then the fulfillment (and rejection) handlers in the job queue are executed, and then also the setTimeout and setInterval handlers are also executed? Is this how the fulfillment handler table and job queue work?

nonopolarity
  • 146,324
  • 131
  • 460
  • 740

1 Answers1

1

Is it true that the resolve() function and then() function below are the only functions in the ES6 Promise mechanism that look at and add the fulfillment handlers to the job queue?

Yes. (reject also looks at the table and removes handlers without adding them to the job queue).

Is it true that the then(fn) will add the fn to the fulfillment handler table (not job queue) for this promise, or if the promise has already been resolved, directly add the fn to the job queue?

Yes.

and the fn is marked as "already added to job queue" and no need to be added again?

No, the fn is not marked at all. It could be passed multiple times to then, in which case it would need to be run multiple times.
But yes, the fulfillment handler table is cleared when the promise fulfills and the callback jobs are scheduled.

And in any event, suppose there are fn1, fn2, fn3, ... etc in the fulfillment handler table, each one is added to the job queue as fn1(resolvedValue), where the resolvedValue is remembered internally by the resolve(resolveValue) call?

Yes. Although technically resolve does not always fulfill the promise.

And there are no other situation where the fulfillment handler table is accessed at all.

Yes. I wonder why you care though.

The job queue jobs are executed by the JS event loop, so that when all the GUI "click event handlers", etc are done, then the fulfillment (and rejection) handlers in the job queue are executed, and then also the setTimeout and setInterval handlers are also executed? Is this how the fulfillment handler table and job queue work?

Yes. However notice that click handlers, setTimeout and setInterval have a separate event queue from promise jobs.

Bergi
  • 630,263
  • 148
  • 957
  • 1,375
  • Q: "And there are no other situation where the fulfillment handler table is accessed at all." A: "Yes. I wonder why you care though." The reason is, before, I thought there might be some system loop that constantly look at the promise handlers and decide whether to run them. And then later on, it appears there is no such loop as the precise moment where these handlers can be executed (or added to a job queue to be executed) is known: either at the `resolve()` moment or the `then()` moment – nonopolarity Dec 25 '19 at 10:32
  • Ah, I see. Yes, there is no part of the event loop that tracks all individual promises, that would be pretty inefficient. There might be optimisations applied where handlers are not "moved" from the fulfillment handler table to the job queue and instead just a reference being created (so that the table becomes "part of" the queue), but those shouldn't change the conceptual model. – Bergi Dec 25 '19 at 11:04