Open jZhangTk opened 2 years ago
Hi, sorry for the late reply!
Can you send an MRE? I just tested a simple node.js project with worker threads using your configuration, and I was unable to replicate the issue.
@mxsdev I'm sorry, what do you mean by MRE?
As I did a quick test with simple worker threads, it indeed worked. There must be something special I'm doing in my project caused the behaviour. Let me dig a little further and get back to you.
Actually, it is not worker_threads
but threads causing the issue.
Steps to reproduce:
npm i threads
in that foldernew Worker()
(excluded) and Thread.terminate()
(included), or inside of the work()
functionindex.js
Once it hits the breakpoint, you should see the behaviour described earlier (VS Code works just fine though). In addition, once the thread is terminated (e.g. console.log('done')
), everything is back to normal. It seems like something is acting up with the threads created by new Worker()
.
// index.js
const { spawn, Thread, Worker } = require('threads');
const main = async function () {
const worker = new Worker('./worker.js');
const instance = await spawn(worker);
await instance.work();
await Thread.terminate(instance);
console.log('done');
};
main();
// worker.js
const { expose } = require('threads');
expose({
work() {
console.log('hello world');
},
});
I'm trying to debug with worker threads. When it hits a breakpoint (DapStopped sign shows up), I can't continue, step over, inspect a variable, etc. It acts as it doesn't know it hit a breakpoint. When I do
:lua require'dap'.continue()
to continue, it gives meAnd when I do
:lua require'dap.ui.widgets'.hover()
to inspect a variable, it gives meBelow is my config for javascript. It works perfectly without worker threads. And it also works in VS Code with worker threads (with
"type": "node"
).Is this a bug or misconfiguration?