4.1 The bridge
Google's v8 engine executes the JS code fetched and loaded into v8 by Deno. Once the code is loaded into v8, is Deno done with its responsibilities? Can it take a seat back while v8 finishes with the program? The answer is a big no.
The v8 engine strictly supports everything that is present in the ECMAScript specification. Anything outside of the ECMAScript specification is the responsibility of the user of the v8.
For example, the basic console.log function is not a part of the ECMAScript specification. This function needs to be implemented by the user of the v8. For another example, making an HTTP call to a server is also not a part of the ECMAScript specification. This function also needs to be implemented by the user of the v8.
Some more examples are file, process, network, system operations.
In short, v8 needs support for anything outside the ECMAScript specification.
The JS application executes in v8. Deno's role is to provide support for everything that's outside the specification.
The path between the user of v8 (i.e. Deno) and v8 can be visualized as a bridge. The reason being that v8 and Deno are different. This bridge is a two-way bridge. There is a predefined way to cross this bridge and come back.
Crossing the bridge is no different than calling a function. However as v8 is different and Deno is different, we call it a bridge. Deno is not a part of v8. Deno is a separate software that is written in Rust. V8 is completely different. They work together, but they are different.
Whenever v8 encounters something outside of the ECMAScript specification, it does the following:
- For any function call,
- Check its name in internal data structures
- If the function is known,
- Call it
- Else
- If the user has registered an external function
- Pause execution
- Call that function
- Resume when a response is available
- Else
- Raise an error
The external functions are called external references. They need to be registered in advance so that v8 knows about them.
At startup, Deno registers all the external references with v8. This is to ensure that v8 has them configured whenever the core Deno runtime gets loaded. Here is the complete list of all the external references registered by Deno:
- print
- recv
- send
- set_macrotask_callback
- eval_context
- shared_getter
- queue_microtask
- encode
- decode
- get_promise_details
- get_proxy_details
That's all! We'll go over some common functions in the next sections. We won't be able to go over all of them.
It is interesting to see that Deno doesn't register any of the ops explicitly. There are three reasons for it:
- The number of ops would always keep increasing
- It'd be tough to standardize responses
- All the ops need to be aware of their caller
Deno hides all the ops behind the send function. V8 calls the send function which routes to the ops.
--
Let's go over select external references in the next sections.
Last modified 2yr ago