3

When javascript runtime finds setTimeout() method, it sends it to Event table. How does runtime know that setTimeout() is a WEB API? Does it first look for setTimeout() method in the current context and then if not found assumes it as a WEB API?

user3760894
  • 267
  • 4
  • 13
  • "*When javascript runtime finds setTimeout() method*" - you've got this backwards. The embedder *provides* the `setTimeout` method to the runtime, without the web api the method simply wouldn't exist in the environment. – Bergi Aug 15 '22 at 16:32
  • Do you mean "how does it know to use the built-in setTimeout function, and not a user-defined function with the same name?" – IMSoP Aug 15 '22 at 16:32
  • There's nothing the runtime needs to "identify". It simply *calls* the method, like any other builtin method, and the implementation of the method (the code that is being executed) sends the callback to the timer table. It's the function that knows what to do, not the runtime. – Bergi Aug 15 '22 at 16:33

2 Answers2

6

When javascript runtime finds setTimeout() method, it sends it to Event table.

JavaScript doesn't "know" or care what setTimeout does. :-) It's just that setTimeout is one of the functions defined in the host environment provided to the JavaScript engine by the host (the browser, in your example). When you use JavaScript to call the function, the function's implementation (provided by the host environment) is executed with the information you provide. It's the host, not the JavaScript engine, that knows what to do with the arguments you provide to setTimeout.

When the host (the browser or Node.js or whatever) needs to create a new runtime environment (for instance, for a window), one of the things it does is create an object to be the host-provided global object for that environment (more properly called a realm), including putting any properties on that object (like setTimeout) that provide host-defined features. It provides that object to the JavaScript engine via what the JavaScript specification calls the InitializeHostDefinedRealm abstract operation. When the JavaScript engine runs your code that uses setTimeout, it sees the identifier setTimeout and looks in the current execution context to see if setTimeout is defined there; if it isn't, the engine looks at the parent execution context, and so on, until it reaches the global execution context, which gets its globals from the host-provided global environment (in part; it also has other globals). So, having found the function matching setTimeout, the JavaScript engine calls that function — which runs the host-defined code for the function, which sets the timer.

So the JavaScript engine doesn't know what setTimeout does, just that there is a setTimeout function on the global object it got from the host.

T.J. Crowder
  • 1,031,962
  • 187
  • 1,923
  • 1,875
  • Thanks for your response. I'm trying to understand how does it know it is defined in the host environment? Is it like whatever JavaScript runtime does not "know", expects that to be defined in the host environment? – user3760894 Aug 15 '22 at 16:36
  • 1
    No, the host environment tells the JavaScript engine what functions it would like to register when it initializes the engine. – CherryDT Aug 15 '22 at 16:38
  • 1
    @user3760894 - The host (browser, Node.js, etc.) creates the object that has the `setTimeout` method on it, and gives it to the JavaScript engine as part of the initialization of a runtime for the particular window (in the browser case). I'll expand the answer to explain that more fully. – T.J. Crowder Aug 15 '22 at 16:42
  • Thanks. So a browser environment would register certain functions, and a nodejs environment would register some other functions. so what if there is a similar function defined in the source code? will that get a preference? – user3760894 Aug 15 '22 at 16:43
  • @CherryDT - Sorry, was that addressed to me or the OP? Am I missing a subtlety? (Wouldn't be the first time. :-) ) In the above I'm speaking of `InitializeHostDefinedRealm`... – T.J. Crowder Aug 15 '22 at 16:45
  • 1
    @user3760894 - *"...so what if there is a similar function defined in the source code? will that get a preference..."* Normal identifier resolution applies, there's nothing special. If you define a `setTimeout` in an inner scope, it will get used by other code in that scope (or a nested scope), a process called *shadowing* the identifier. `setTimeout` is a global, so any local definition will shadow it. (Doing so is generally not a good idea. :-) ) – T.J. Crowder Aug 15 '22 at 16:54
  • 1
    @T.J.Crowder Oh - it was addressed to the OP. I forgot the @. To be honest I don't even know why I replied, the question would have been answered by you anyway! Sorry for the confusion. – CherryDT Aug 15 '22 at 17:50
  • @CherryDT - No worries at all! :-) I just didn't want to assume. Happy coding! – T.J. Crowder Aug 15 '22 at 18:14
1

In terms of identifying which function to run, it doesn't make any difference whether a function is built into the engine, or added at run-time (this fact is really useful, allowing functions to be "polyfilled" if the engine doesn't provide them).

When you write foo(), JS actually looks for a variable with that name (this unification of variables, properties, functions and methods is an unusual feature of JS). It looks for it first in the local scope, then in the parent of that scope, and so on up the "scope chain".

The last place it looks is the "global object", which in a browser is the window object. So if you define window.foo as a function, you can call foo() from anywhere that doesn't have its own function called foo in scope.

Built-in functions work just the same way: when the JS engine starts up, it (conceptually) defines a whole bunch of functions on the window object, with special implementations referring to internal operations in the engine rather than composed of JS code.

So when you call setTimeout, JS walks up the scope chain, and if it doesn't find anything else, will find the setTimeout function registered by the engine, and runs it. The engine then does whatever it wants to do with that - hopefully, something that complies with the behaviours described in the current ECMAScript standard.

IMSoP
  • 89,526
  • 13
  • 117
  • 169