-1

Taking the setTimeout method as an example, how does JavaScript know that that specific method is asynchronous? How does it know that it has to push the method into the queue of the event loop ?

Can anyone throw some light on this ?

Thank you.

Kamoukou
  • 123
  • 1
  • 2
  • 6
  • Because that is what the specification says so they coded it that way? – epascarello Nov 22 '17 at 01:44
  • 2
    The `setTimeout()` method is synchonous, but triggers an asynchronous process. It's a built-in method, so it's not like JS has to guess... – nnnnnn Nov 22 '17 at 01:44
  • @ObsidianAge not sure what you're talking about. Most of javascript is synchronous unless something is specifically documented as being asynchronous... – Damon Nov 22 '17 at 01:45
  • 1
    [This article](https://blog.sessionstack.com/how-javascript-works-event-loop-and-the-rise-of-async-programming-5-ways-to-better-coding-with-2f077c4438b5) explains how JavaScript queues functions under the hood quite well. – Arman Charan Nov 22 '17 at 01:47
  • 2
    @ObsidianAge You’ve got that exactly backwards. JavaScript is synchronous, by nature, period. You call Web APIs that are implemented by the client and the client carries them out asynchronously. – Scott Marcus Nov 22 '17 at 01:49
  • 1
    This talk may help: https://youtu.be/8aGhZQkoFbQ – Jonathan Nov 22 '17 at 01:50
  • @ObsidianAge - WHAT? are you one of those *"promises make asynchronous code synchronous"* conspiracy theorists? – Jaromanda X Nov 22 '17 at 01:51

2 Answers2

0
var queue = [];
function add(callback) {
    queue.push(callback);
}

How does JavaScript know that it has to push the callback function to the queue array?

It doesn't "know". It just executes the add function.

It's not any different for setTimeout - except that the function is not written by the JavaScript programmer, but exposed as part of the native API built into the browser. JavaScript does not know what it does, it just calls it.

Bergi
  • 630,263
  • 148
  • 957
  • 1,375
0

First, understand that JavaScript runs within its own execution environments (a runtime). That runtime is just one application running within the host operating system and that OS is capable of muti-threading (asynchronous operations). The JavaScript runtime can be doing one thing while the OS does something else.

The JavaScript runtime processes all code synchrously. This is by design and written into the ECMAScript specification. So, there is nothing that the runtime has to figure out.

Most clients provide additional APIs (beyond what’s in the spec.) and those operations are often done asynchronously because they aren’t being done by the runtime - they are being done by the client. setTimeout() is an example of this. It’s not part of JavaScript. It’s part of the browser supplied window object and the timer is actually carried out by the browser.

Scott Marcus
  • 64,069
  • 6
  • 49
  • 71
  • Actually promise asynchrony is in the spec now. – Bergi Nov 22 '17 at 02:14
  • @Bergi Promises aren’t asynchronous. They are simply a way to manage callbacks that are triggered by asynchronous operations. They do not add asynchronicity to JavaScript. – Scott Marcus Nov 22 '17 at 02:35
  • That's not true. There is an inherent asynchrony between the `resolve` call and the `then` callbacks, also between the `then` call on a fulfilled promise and the callback execution - mandated by [the standard](https://promisesaplus.com/#point-34) that ES6 followed. You can try `Promise.resolve("asynchronous").then(console.log); console("immediate")` – Bergi Nov 22 '17 at 02:56
  • @Bergi It is true. All the spec says is how to handle the results of the asynchronous call, not to perform it. The actual asynchronous operation is not carried out by the JS runtime. – Scott Marcus Nov 22 '17 at 03:01
  • What do you mean by "asynchronous call"? There is no asynchronous environment method in my example, just the promise code. And still it behaves asynchronously, using the promise job queue. – Bergi Nov 22 '17 at 03:04
  • @Bergi I mean the actual work happening in a different thread. Promises don’t add asynchronousity to JavaScript. They are just a mechanism for managing the results of asynchronous operations. – Scott Marcus Nov 22 '17 at 03:15
  • It's not necessary for "work" (if waiting for a timer or network response can be called that) happening in a different thread to have an asynchronous callback. *Asynchrony* only means that it will be run after the current run-to-completion. Promises *do* provide that, even if it doesn't do much more than e.g. `setImmediate` or `process.nextTick`. – Bergi Nov 22 '17 at 03:22
  • @Bergi Well, now we get to the point of contention. Asynchronous does not mean it will be run once the JS runtime is idle. That’s a description of how a call back is handled. Asynchronous literally means two (or more) things happening simultaneously and JavaScript does not do that. As I said, Promises are simply a mechanism for managing what happens after the asynchronous operation is complete. – Scott Marcus Nov 22 '17 at 03:27
  • I think now you're confusing [asynchronous](https://en.wikipedia.org/wiki/Asynchrony_(computer_programming)) with [concurrent](https://en.wikipedia.org/wiki/Concurrency_(computer_science)) or [parallel](https://en.wikipedia.org/wiki/Parallel_computing). – Bergi Nov 22 '17 at 03:35
  • @Bergi Have you read the Wiki article you linked to? It supports my point and discounts yours. It says that asynchrony provides a degree of parallelism and it goes on to talk about a common way to “deal” with asychrony is through Promises. Not that Promises are asychrony. – Scott Marcus Nov 22 '17 at 03:42
  • *A common way for dealing with asynchrony in a programming interface is to provide subroutines (methods, functions) that return to their caller an object, sometimes called a future or promise, that represents the ongoing events. Such an object will then typically come with a synchronizing operation that blocks until the operation is completed. Some programming languages, such as Cilk, have special syntax for expressing an asynchronous procedure call.* – Scott Marcus Nov 22 '17 at 03:45
  • Another example, XMLHttpRequest.send() is asynchronous. The XMLHttpRequest.onreadystatechange callback is not. – Scott Marcus Nov 22 '17 at 03:51