Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

module: warn of potential for deadlock with hooks worker #51035

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from
Draft
Show file tree
Hide file tree
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 11 additions & 0 deletions doc/api/module.md
Original file line number Diff line number Diff line change
Expand Up @@ -111,6 +111,17 @@ changes:
Register a module that exports [hooks][] that customize Node.js module
resolution and loading behavior. See [Customization hooks][].

> **Warning** When setting up a `MessageChannel` to communicate with hooks,
> beware that this can lead to a deadlock. For example, you have 2 modules,
> A and B. "A" is registered first and sets up a message channel, which it uses
> in its `resolve` hook. After "A" is registered, "B" is registered. Resolving
> "B"'s specifier will go through "A"'s `resolve` hook, which will try to
> communicate with a locked thread that is busy trying to register "B"'s hooks.
> Since registering "B" depends on resolving "B"'s specifier, and resolving
> "B"'s specifier is blocked by "A"'s communication request that is itself
> blocked by the pending registration that started the chain, the application
> becomes deadlocked.
Comment on lines +114 to +123
Copy link
Contributor

@aduh95 aduh95 Dec 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this need a TLDR, in particular it needs an introduction sentence explaining what not to do – because let's be honest, I don't think anyone will be interested in the particular details unless they are running into that specific issue.
Maybe we can also tune down the details a lot, a vague explanation might be preferable.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TLDR: if there are multiple loaders and at least one uses MessageChannel, you will probably footgun

Copy link
Contributor

@aduh95 aduh95 Dec 3, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we keep it as that?

Suggested change
> **Warning** When setting up a `MessageChannel` to communicate with hooks,
> beware that this can lead to a deadlock. For example, you have 2 modules,
> A and B. "A" is registered first and sets up a message channel, which it uses
> in its `resolve` hook. After "A" is registered, "B" is registered. Resolving
> "B"'s specifier will go through "A"'s `resolve` hook, which will try to
> communicate with a locked thread that is busy trying to register "B"'s hooks.
> Since registering "B" depends on resolving "B"'s specifier, and resolving
> "B"'s specifier is blocked by "A"'s communication request that is itself
> blocked by the pending registration that started the chain, the application
> becomes deadlocked.
> **Warning** If a `resolve` or `load` is left pending on a response from a
> `MessageChannel`, that will cause a deadlock when the main thread is
> "asleep" waiting for a response from the loader thread. To avoid that,
> always set a timeout when dealing with cross thread communication
> inside those hooks.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

waiting for a response from the hooks rather than loader thread. In this case just "hooks" is better than "hooks thread" because there could beer multiple hooks threads (for now).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To avoid that, always set a timeout when dealing with cross thread communication inside those hooks.

This is never going to be a suitable solution, it would be better not to suggest it.

Either the timeout will be too short, and will cancel requests that would not be deadlocked, or it's too long, and will incur a startup penalty equal to the length of the timeout when they are deadlocked. There's no reliable way to tune it to only cancel when it would be deadlocked, without significant perf penalties.

Furthermore, just canceling the request may actually not be what you want. Consider a transpiler loader that converts TypeScript into JavaScript, but has to talk to a service on the main thread to know how to do that correctly. If any Module.register() is called after this loader is registered, and the second loader is written in TypeScript, it's going to deadlock until the timer expires, then... what? Throw an error? Serve TypeScript to v8 uncompiled?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I’d throw an error. After say one second of idling, it’s time to give up. It’s not a perf penalty, it’s a DX thing, querying the main thread is kind of like making a network call, you should always treat the case when you never get a response to not keep your users waiting indefinitely.


### `module.syncBuiltinESMExports()`

<!-- YAML
Expand Down
23 changes: 23 additions & 0 deletions test/known_issues/hooks-thread/a/hooks.mjs
JakobJingleheimer marked this conversation as resolved.
Show resolved Hide resolved
Original file line number Diff line number Diff line change
@@ -0,0 +1,23 @@
let port;

export function initialize(data) {
({ port } = data);
}

export function resolve(specifier, context, nextResolve) {
const id = ''+Math.random();
port.postMessage({
context,
id,
specifier,
});

return new Promise((resolve) => {
port.on('message', (message) => {
if (message.id !== id) return;

port.off('message', onMessage);
resolve({ url: message.specifier });
});
});
}
15 changes: 15 additions & 0 deletions test/known_issues/hooks-thread/a/register.mjs
Original file line number Diff line number Diff line change
@@ -0,0 +1,15 @@
import { register } from 'node:module';
import { MessageChannel } from 'node:worker_threads';

const { port1, port2 } = new MessageChannel();

port1.unref();
port2.unref();

register((new URL('./hooks.mjs', import.meta.url)).href, {
data: {
port: port2,
},
parentURL: import.meta.url,
transferList: [port2],
});
9 changes: 9 additions & 0 deletions test/known_issues/hooks-thread/b/hooks.mjs
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
// This file will not get loaded because of a deadlock trying to resolve it.

export function resolve(specifier, context, nextResolve) {
return nextResolve(specifier, context, nextResolve);
}

export function load(url, context, nextLoad) {
return nextLoad(url, context, nextLoad);
}
9 changes: 9 additions & 0 deletions test/known_issues/hooks-thread/b/register.mjs
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
import { register } from 'node:module';
import { MessageChannel } from 'node:worker_threads';

const { port1, port2 } = new MessageChannel();

port1.unref();
port2.unref();

register((new URL('./hooks.mjs', import.meta.url)).href);
42 changes: 42 additions & 0 deletions test/known_issues/hooks-thread/test-hooks-thread-deadlock.js
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
const { mustNotCall } = require('../../common/index.js');
const assert = require('node:assert');
const { spawn } = require('node:child_process');
const path = require('node:path');
const { execPath } = require('node:process');
const { describe, it } = require('node:test');

describe('hooks deadlock', { concurrency: true }, () => {
it('will deadlock when a/hooks…resolve tries to contact the main thread during b/register', async () => {
let stderr = '';
let stdout = '';
// ! Do NOT use spawnSync here: it will deadlock.
const child = spawn(execPath, [
Copy link
Contributor

@aduh95 aduh95 Dec 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You want to write the test as you'd like Node.js to work, i.e. if we ever fix the bug, we should just have to git mv test/known_issues/test-hooks-deadlock.js test/es-module

Suggested change
const child = spawn(execPath, [
const result = await spawnPromisified(execPath, [

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How do I then verify it is indeed "broken"? spawnPromisified will cause the process to hang.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I would call that broken, isn’t that good enough?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I mean it would break CI. The test as currently written demonstrates that the targeted behaviour is broken. Do these tests work differently?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, known_issues are for tests that are not passing (but we'd like them to). E.g. out/Release/node test/known_issues/test-vm-ownkeys.js exits with non-zero code, and tools/test.py test/known_issues/test-vm-ownkeys.js shows "All tests passed".

`--import=${path.resolve(__dirname, './a/register.mjs')}`,
`--import=${path.resolve(__dirname, './b/register.mjs')}`,
JakobJingleheimer marked this conversation as resolved.
Show resolved Hide resolved
'--input-type=module',
'--eval',
'import.meta.url;console.log("done")',
]);
child.stderr.setEncoding('utf8');
child.stderr.on('data', (data) => { stderr += data; });
child.stdout.setEncoding('utf8');
child.stdout.on('data', (data) => { stdout += data; });

child.on('close', () => mustNotCall('Deadlock should prevent closing'));

return new Promise((res, rej) => {
setTimeout(() => {
try {
assert.strictEqual(stderr, '');
assert.strictEqual(child.exitCode, null); // It hasn't ended
assert.strictEqual(child.signalCode, null); // It hasn't ended

assert.strictEqual(child.kill('SIGKILL'), true); // Deadlocked process must be forcibily killed.
res('deadlocked process terminated');
} catch (e) {
rej(e);
}
}, 5_000); // This should have finished well before 5 second.
});
});
});