-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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
base: main
Are you sure you want to change the base?
Changes from 4 commits
24490e8
c72fc75
d9f61cb
7068d97
462d8f2
816cb01
7c07922
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
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 }); | ||
}); | ||
}); | ||
} |
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], | ||
}); |
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); | ||
} |
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); |
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, [ | ||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. How do I then verify it is indeed "broken"? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would call that broken, isn’t that good enough? There was a problem hiding this comment. Choose a reason for hiding this commentThe 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? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, |
||||||
`--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. | ||||||
}); | ||||||
}); | ||||||
}); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?There was a problem hiding this comment.
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.