Native prototype of ECMAScript AsyncContext proposal using existing public v8::Context methods

[benjamn]

tl;dr

These changes have been published in the benjamn/deno:async-context Docker image, building on the work in PR #1, meaning you should be able to run my custom build of Deno (if you have Docker installed) using the following command:

docker run -it --rm benjamn/deno:async-context repl

# Alternatively, for 'thenables' support:
docker run -it --rm benjamn/deno:async-thenables repl

That command will open a JavaScript REPL where the AsyncContext constructor is available and fully implemented (according to my understanding of the proposal).

Why now

I realize it's too early in the TC39 proposal stage process to be deciding anything about the implementation. I am not advocating for this specific implementation (nor promoting Deno or Docker) over any other good ideas.

However, this is a subtle proposal, and many of the interested parties bring intuitions from previous systems with goals similar to those motivating AsyncContext, but with slightly different concrete usage, semantics, pitfalls, etc.

I hope this implementation allows those folks to check their intuitions thoroughly, especially in scenarios where the flow of AsyncContext could be needlessly lost (so explicit AsyncContext.wrap binding may be necessary).

Also, I believe everyone interested in these topics should at least be aware of v8::Context::GetContinuationPreservedEmbedderData and SetContinuationPreservedEmbedderData, which provide a purpose-built way to hook into low-level PromiseReactionJob creation and execution, automatically bridging an all-important asynchronous gap in the ECMAScript event loop system.¹

Details

With this implementation, AsyncContext values are automatically preserved throughout the bodies of native async functions, even after one or more await expressions, and also not exposed during asynchronous pauses to other unrelated code that might happen to be running on the event loop in the meantime.

Similarly, typical use of Promises (chaining then and catch and finally) should propagate AsyncContext as expected. As a bonus, setTimeout and setInterval now use AsyncContext.wrap to ensure context continuity for their callbacks.

As a concrete demonstration, these expect assertions pass:

const ctx = new AsyncContext;
ctx.run(1234, async () => {
  expect(ctx.get()).toBe(1234);
  const setTimeoutResult = await ctx.run(
    2345,
    () => new Promise(resolve => {
      setTimeout(() => resolve(ctx.get()), 20);
    }),
  );
  expect(setTimeoutResult).toBe(2345);
  expect(ctx.get()).toBe(1234);
  return "final result";
}).then(result => {
  expect(result).toBe("final result");
  // The code that generated the Promise has access to the 1234
  // value provided to ctx.run above, but consumers of the Promise
  // do not automatically inherit it.
  expect(ctx.get()).toBeUndefined();
});

If you want something that's easier to paste into the Deno REPL, try this:

const ctx = new AsyncContext;
ctx.run(1234, async () => {
  console.log("before await", ctx.get());
  const setTimeoutResult = await ctx.run(
    2345,
    () => new Promise(resolve => {
      setTimeout(() => resolve(ctx.get()), 20);
    }),
  );
  console.log("after await", ctx.get());
  console.log({ setTimeoutResult });
  return "final result";
}).then(result => {
  console.log("final result?", result);
  console.log("outside ctx.run", ctx.get());
})

If all goes well, the console output should be:

before await 1234
Promise { <pending> }
> after await 1234
{ setTimeoutResult: 2345 }
final result? final result
outside ctx.run undefined

Why did I choose Deno?

A few reasons, none of which conflict with my love of Node.js:

• I wanted to improve my Rust skills
  • Please let me know if you spot any better ways to do the Rust parts
• You could probably implement the AsyncContext proposal using the Node.js async_hooks utilities (like AsyncLocalStorage), but I wanted to show that is not necessary
  • V8 already provides the raw materials via two existing methods of v8::Context, which were introduced in this cryptic/convenient V8 pull request back in March 2020²
• Deno builds to a single standalone static binary, which makes it possible to distribute with a relatively small Docker image (162MB total, 89MB of which are that deno binary)

I'd be happy to try something similar with Node.js, if there's interest.

Why am I using Docker?

If you happen to have Docker installed, downloading and running a ready-to-go 162MB image is likely to be much faster than cloning the necessary repositories and submodules and building everything from source, which can take more than an hour on my late-model Intel Macbook Pro.

If you don't have access to Docker, the docker/ directory is still a good reference for how to build the project from source.

Building from source may also be worthwhile if you want to use the custom version of deno as your deno.path in .vscode/settings.json, so that (for example) AsyncContext will be known by the type system to be globally defined when using the Deno VSCode integration.

Footnotes

1. I don't think these v8::Context::{Get,Set}ContinuationPreservedEmbedderData methods should ever be exposed directly to userland code (global mutable state of the worst kind 😱), but I would argue AsyncContext wraps a safe abstraction over that fundamental capability, achieving continuity of AsyncContext across PromiseReactionJob creation and execution without exposing any of the necessary global state for tampering. ↩

2. World events may have overshadowed the news of this pull request landing in V8 ↩

[benjamn]

This is what I meant by avoiding "Promise.prototype.then wrapping."

[benjamn]

That failing test was using the old benjamn/deno:async-context image, which did not fully support AsyncContext with "thenable" objects (any object with a then method). Once I update the test to use the newer benjamn/deno:async-thenables Docker image, the new tests should all pass…

[benjamn]

This new test demonstrates AsyncContext is now preserved even when using Promise-like thenable objects (any object with a function-valued then method). This behavior did not work with my previous Docker image benjamn/deno:async-context, but it works now with benjamn/deno:async-thenables.

Technically, adding support for thenables boiled down to making PromiseResolveThenableJobTask behave more like PromiseResolveReactionJob, in benjamn/deno-v8@d72a3dd, my fork of Deno's fork of V8.

This change was inspired by two comments from @jridgewell:

• AsyncLocalStorage without Async Hooks nodejs/node#46265 (comment)
• AsyncLocalStorage without Async Hooks nodejs/node#46265 (comment)

There might be a better way to handle all kinds of host reaction jobs at once, but improving AsyncContext support for thenables to match other patterns of Promise and async/await usage seems like an improvement to me.

I know it's not this simple to change how V8 processes thenables/anything, with so many dependent projects (Node.js, Deno, Chromium, etc) who would all have to be on board (or indifferent). I also know I'm probably not showing the people who make these decisions anything they don't already know, but for me it's been useful to play with a prototype where AsyncContext and thenables work together.

In other words, I don't claim to be fully addressing the last remaining concern expressed in cloudflare/workerd#282 (comment), but here's a REPL you can play with right now to see what I'm talking about:

docker run -it --rm benjamn/deno:async-thenables repl

Try pasting in this code:

const c = new AsyncContext();
c.run(1234, async () => {
  console.log("before await", c.get());
  const onResResult = await {
    then(onRes) {
      return Promise.resolve(onRes(c.get()));
    }
  };
  console.log("after await", c.get(), { onResResult });
})

If all goes well, that code should log

before await 1234
after await 1234 { onResResult: 1234 }
Promise { undefined }

However, if you try the same code with my previous Docker image benjamn/deno:async-context…

docker run -it --rm benjamn/deno:async-context repl

then the result will be

before await 1234
after await 1234 { onResResult: undefined }
Promise { undefined }

For more examples, see the test code I'm commenting on.

[jridgewell]

Lol, we were just talking about making these exact changes yesterday on our Matrix chat. If you're on Matrix, I'd love to add you to our group chat.

There might be a better way to handle all kinds of host reaction jobs at once, but improving AsyncContext support for thenables to match other patterns of Promise and async/await usage seems like an improvement to me.

Yes, I think instead of implementing these for each individual enqueable task type, the queue itself should implement this for all types. But for now, this fix is exactly what I recommended in our chat.

[benjamn]

If you're on Matrix, I'd love to add you to our group chat.

Sure! I'm a Matrix newb though I've used it a bit for TC39. I think @benjamn:matrix.org is my handle?

[jridgewell]

You're invited.

[Jbnado]

What is this Matrix?

[jridgewell]

https://matrix.to/#/#tc39-async-context:matrix.org