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

How to close inspector in worker thread? #3651

Closed
ds3p2 opened this issue Dec 13, 2021 · 8 comments
Closed

How to close inspector in worker thread? #3651

ds3p2 opened this issue Dec 13, 2021 · 8 comments

Comments

@ds3p2
Copy link

ds3p2 commented Dec 13, 2021

Details

I am trying to enable some debugging in the worker thread programmatically. I read the Inspector API and trying to implement it in the worker thread model.
Currently I am not sure which is the proper way to use the inspector module in worker thread.
The sample code shows how I am using inspector.

  • I found inspector.open can be called in the worker thread, and the created inspector only works in the current thread. Breakpoints in other thread / main thread will be just ignored.
  • However, I found inspector.close is undefined in worker thread. According to fix(worker): allow inspector.close() inside Worker node#30680, this is the expected behavior. But the question is how do I close the debugger port created in the worker thread?

Node.js version

14.15.5

Example code

const {
  isMainThread,
  parentPort,
  Worker,
  workerData,
} = require("worker_threads");
const inspector = require("inspector");

if (isMainThread) {
  console.log("in main thread", inspector.close);
  // inspector.open(9231, "127.0.0.1", true);  // Uncomment this line will get error "Inspector is already activated"
  const worker1 = new Worker(__filename, { workerData: { id: 1 } });
  const worker2 = new Worker(__filename, {
    workerData: { id: 2 },
  });
  let cnt = 0;
  worker1.on("message", () => {
    cnt++;
  });
  worker2.on("message", () => {
    cnt++;
  });
} else {
  if (workerData.id === 1) {
    console.log("in worker thread", inspector.close);
    inspector.open(9229, "127.0.0.1", true);
    const content = "I am worker: " + workerData.id;
    setInterval(() => {
      console.log(content);
      parentPort.postMessage("done");
    }, 1000);
  } else {
    console.log("in worker thread", inspector.close);
    inspector.open(9230, "127.0.0.1", true);
    const content = "I am worker: " + workerData.id;
    setInterval(() => {
      console.log(content);
      parentPort.postMessage("done");
    }, 1000);
  }
}

Operating system

Mac OS 12.0.1

Scope

code, runtime

Module and version

Not applicable.

@addaleax
Copy link
Member

@ds3p2 I think the best way to address this would be to always open/close the inspector server from the main thread, and then communicate to the worker threads using that?

@ds3p2
Copy link
Author

ds3p2 commented Dec 13, 2021

@addaleax
My case is a little special.
I suppose different threads are running tasks belongs to different owners, and there will be more than one developer doing debugging at the same time, each focusing on one specific thread. If I use an inspector from the main thread, then developer may accidentally comes across breakpoint from other thread or the main thread (when some of them do not set proper breakpoint condition).
Although I did not find relative statement in any document, I am quite satisfied with the current behavior that the inspector created in a worker thread is "scoped".

@addaleax
Copy link
Member

@ds3p2 I guess you could also use the inspector.Session API and host the TCP server yourself, for each thread?

Although I did not find relative statement in any document, I am quite satisfied with the current behavior that the inspector created in a worker thread is "scoped".

I don’t think this is the intended use case here – if you do want to get into a situation in which there can be more than one built-in inspector TCP server per process, I think that would require some work on Node.js itself.

@ds3p2
Copy link
Author

ds3p2 commented Dec 13, 2021

@addaleax

I guess you could also use the inspector.Session API and host the TCP server yourself, for each thread?

I do not quite understand your suggestion. In the main process I cannot call inspector.open multiple times (Error Inspector is already activated. Close it with inspector.close() before activating it again.). Even if I can create separate session for each thread, how do the developer specify which thread to debug when trying to attach to the same debug port?

I don’t think this is the intended use case here – if you do want to get into a situation in which there can be more than one built-in inspector TCP server per process, I think that would require some work on Node.js itself.

I am not sure if I understand this correctly. Are you suggesting that inspector.open should not be called inside a worker thread? If so, why not disable the API just like inspector.close?

@addaleax
Copy link
Member

Are you suggesting that inspector.open should not be called inside a worker thread?

Yes.

If so, why not disable the API just like inspector.close?

I don’t know?

@ds3p2
Copy link
Author

ds3p2 commented Dec 13, 2021

@addaleax
OK, it seems I need to look for some other approach.
Is there any official document where usage of inspector.open in worker thread is discouraged?

@addaleax
Copy link
Member

@ds3p2 No, but I assume there should be one in https://nodejs.org/api/inspector.html#inspectoropenport-host-wait. It’s a bit unfortunate that the inspector API was never really well-documented to begin with 😕

@ds3p2
Copy link
Author

ds3p2 commented Dec 13, 2021

@addaleax
It's OK, thanks for your kind help. I am closing this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants