A Guide to Deno Core
Search…
Process Lifecycle
Rust main() Entry Point
A Deno process starts with the
main function in src/main.rs:src/main.rs
1
fn main() {
2
log::set_logger(&LOGGER).unwrap();
3
let args = env::args().collect();
4
let (flags, rest_argv, usage_string) =
5
flags::set_flags(args).unwrap_or_else(|err| {
6
eprintln!("{}", err);
7
std::process::exit(1)
8
});
9
​
10
if flags.help {
11
println!("{}", &usage_string);
12
std::process::exit(0);
13
}
14
​
15
log::set_max_level(if flags.log_debug {
16
log::LevelFilter::Debug
17
} else {
18
log::LevelFilter::Warn
19
});
20
​
21
let state = Arc::new(isolate::IsolateState::new(flags, rest_argv));
22
let snapshot = snapshot::deno_snapshot();
23
let isolate = isolate::Isolate::new(snapshot, state, ops::dispatch);
24
tokio_util::init(|| {
25
isolate
26
.execute("denoMain();")
27
.unwrap_or_else(print_err_and_exit);
28
isolate.event_loop().unwrap_or_else(print_err_and_exit);
29
});
30
}
Copied!
After processing the flags, Deno first creates a V8 isolate (an isolated V8 VM instance with its own heap). We also pass in the snapshot here, which contains serialized heap data about TypeScript compiler and frontend code. This allows much faster startup speed.
Immediately afterwards, we setup Tokio, and ask the isolate to execute a function called
denoMain. Only after it has finished running this function does Deno starting its event loop. Once the event loop stops, the Deno process dies.denoMain()
denoMain is located in js/main.ts.js/main.ts
1
export default function denoMain() {
2
libdeno.recv(handleAsyncMsgFromRust);
3
​
4
const startResMsg = sendStart();
5
setLogDebug(startResMsg.debugFlag());
6
​
7
const compiler = Compiler.instance();
8
​
9
// ... code omitted
10
​
11
const cwd = startResMsg.cwd();
12
​
13
// ... code omitted
14
​
15
const runner = new Runner(compiler);
16
​
17
if (inputFn) {
18
runner.run(inputFn, `${cwd}/`);
19
} else {
20
replLoop();
21
}
22
}
Copied!
First, we tell
libdeno, which is the exposed API from the middle-end, that whenever there is a message sent from the Rust side, please forward the buffer to a function called handleAsyncMsgFromRust. Then, a Start message is sent to Rust side, signaling that we are starting and receiving information including the current working directory, or cwd. We then decide whether the user is running a script, or using the REPL. If we have an input file name, Deno would then try to let the runner, which contains the TypeScript compiler, to try running the file (going deep into its definition, you'll eventually find a secret eval/globalEval called somewhere). denoMain only exits when the runner finish running the file.isolate.event_loop()
With
denoMain running to its end, a set of asynchronous calls might have been made without any of them being responded. Deno would then call the isolate.event_loop() to start the loop.Code for
event_loop is located in src/isolate.rs:src/isolate.rs
1
pub fn event_loop(&self) -> Result<(), JSError> {
2
// Main thread event loop.
3
while !self.is_idle() {
4
match recv_deadline(&self.rx, self.get_timeout_due()) {
5
Ok((req_id, buf)) => self.complete_op(req_id, buf),
6
Err(mpsc::RecvTimeoutError::Timeout) => self.timeout(),
7
Err(e) => panic!("recv_deadline() failed: {:?}", e),
8
}
9
self.check_promise_errors();
10
if let Some(err) = self.last_exception() {
11
return Err(err);
12
}
13
}
14
// Check on done
15
self.check_promise_errors();
16
if let Some(err) = self.last_exception() {
17
return Err(err);
18
}
19
Ok(())
20
}
Copied!
This is literally a loop. Every single time, we check if there is still some events we haven't responded, with
self.is_idle(). If yes, we will wait for self.rx, which is the receiving end of a message channel, to receive some message, or wait for a timer, created by setTimeout, to expire.If
self.rx received some message, this means that one of the task in the Tokio thread pool has completed its execution. We would then process its execution result, which is a pair of req_id (the task id) and buf (the buffer containing serialized response), by sending them to self.complete_op, which forwards the result based on request id and invoke the code that is waiting for this output, running to the end. Notice that the code invoked here might schedule for more async operation.If timeout happens, code scheduled to execute by
setTimeout would similarly be invoked and running to the end.The event loop would continue to wait for output and run more code, until
self.is_idle becomes true. This happens when there are no more pending tasks. Then, the event loop exits and Deno quits.It is possible that an error might happen when executing code, and Deno would exit if such error exists. If it is a promise error (e.g. uncaught rejection), Deno would invoke
self.check_promise_errors to check.Promise Table
In the previous section, we mentioned that
req_id is provided to self.complete_op as a task id. Actually, it is used to retrieve the correct promise created by the past async operation from a promise table, which holds all the promises that are pending resolve.The promise table is located in
src/dispatch.tssrc/dispatch.ts
1
const promiseTable = new Map<number, util.Resolvable<msg.Base>>();
Copied!
Promise table is populated by
dispatch.sendAsync, which is used to forward async requests to Rust.src/dispatch.ts
1
// @internal
2
export function sendAsync(
3
builder: flatbuffers.Builder,
4
innerType: msg.Any,
5
inner: flatbuffers.Offset,
6
data?: ArrayBufferView
7
): Promise<msg.Base> {
8
const [cmdId, resBuf] = sendInternal(builder, innerType, inner, data, false);
9
util.assert(resBuf == null);
10
const promise = util.createResolvable<msg.Base>();
11
promiseTable.set(cmdId, promise);
12
return promise;
13
}
Copied!
The
cmdId here is essentially the req_id on the Rust side. It is returned by sendInternal, which calls into V8 Send binding and increments a global request id counter. For each async operation, we create a deferred/resolvable and place it into the promise table with cmdId as the key.From the
denoMain section, we saw that we attach handleAsyncMsgFromRust to libdeno as the receive callback whenever a new message arrives. Here is its source code:1
export function handleAsyncMsgFromRust(ui8: Uint8Array) {
2
// If a the buffer is empty, recv() on the native side timed out and we
3
// did not receive a message.
4
if (ui8.length) {
5
const bb = new flatbuffers.ByteBuffer(ui8);
6
const base = msg.Base.getRootAsBase(bb);
7
const cmdId = base.cmdId();
8
const promise = promiseTable.get(cmdId);
9
util.assert(promise != null, `Expecting promise in table. ${cmdId}`);
10
promiseTable.delete(cmdId);
11
const err = errors.maybeError(base);
12
if (err != null) {
13
promise!.reject(err);
14
} else {
15
promise!.resolve(base);
16
}
17
}
18
// Fire timers that have become runnable.
19
fireTimers();
20
}
Copied!
Notice that it grabs the
cmdId from the response and find the corresponding Promise in the table. The promise is then resolved, allowing code awaiting the response to be executed as microtasks.Lifecycle Example
For a file looks like the following:
1
// RUN FILE
2
import * as deno from 'deno';
3
​
4
const dec = new TextDecoder();
5
​
6
(async () => {
7
// prints "A"
8
console.log(dec.decode(await deno.readFile('a.c')));
9
// prints "B"
10
console.log(dec.decode(deno.readFileSync('b.c')));
11
// prints "C"
12
console.log(dec.decode(await deno.readFile('c.c')));
13
})();
14
​
15
// prints "D"
16
console.log(dec.decode(deno.readFileSync('d.c')));
17
​
18
// END FILE
Copied!
The Deno process lifecycle control flow graph looks like this:
1
Rust TypeScript (V8)
2
​
3
main
4
|
5
create isolate
6
|
7
| execute
8
|--------------> denoMain
9
|
10
startMsg |
11
|<-------------------|
12
|------------------->|
13
startResMsg |
14
|
15
RUN FILE
16
readFile('a.c') |
17
(thread pool) |<-------------------|
18
|
19
|
20
readFileSync('d.c')|
21
|<-------------------|
22
|
23
blocking
24
execution
25
|
26
|------------------->|
27
(Uint8Array) "D" |
28
console.log("D")
29
|
30
END FILE |
31
|....................| # no more sync code to exec
32
|
33
event loop
34
|
35
more tasks
36
|
37
| 'a.c' done reading
38
(thread pool) |------------------->|
39
(Uint8Array) "A" |
40
console.log("A")
41
|
42
readFileSync('b.c')|
43
|<-------------------|
44
|
45
blocking
46
execution
47
|
48
|------------------->|
49
(Uint8Array) "B" |
50
console.log("B")
51
|
52
readFile('c.c') |
53
(thread pool) |<-------------------|
54
|
55
|....................| # no more sync code to exec
56
|
57
more tasks
58
|
59
| 'c.c' done reading
60
(thread pool) |------------------->|
61
(Uint8Array) "C" |
62
console.log("C")
63
|
64
|
65
|....................| # no more sync code to exec
66
|
67
no task
68
|
69
|
70
v
71
EXIT
Copied!
Last modified 3yr ago