src,worker: add isInternalWorker

[Ceres6]

This PR adds an isInternalWorker to node:worker_threads similar to isMainThread but to detect if the thread is an instance of InternalWorker

[Ceres6]

cc @JakobJingleheimer @bengl

[Ceres6]

Might close nodejs/import-in-the-middle/issues/38

[JakobJingleheimer]

Nicely done!

Maaaybe for consistency with isMainThread, the name should actually be isInternalThread (sorry, I was the one who originally told said isInternalWorker).

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.52%. Comparing base (afafee2) to head (10cbd4a).
Report is 77 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #56469      +/-   ##
==========================================
- Coverage   88.53%   88.52%   -0.02%     
==========================================
  Files         657      660       +3     
  Lines      190761   190898     +137     
  Branches    36616    36626      +10     
==========================================
+ Hits       168899   168996      +97     
- Misses      15048    15089      +41     
+ Partials     6814     6813       -1     

Files with missing lines	Coverage Δ
lib/internal/worker.js	99.81% <100.00%> (+<0.01%)	⬆️
lib/worker_threads.js	100.00% <100.00%> (ø)
src/node_worker.cc	84.15% <100.00%> (+0.20%)	⬆️
src/node_worker.h	90.90% <100.00%> (+0.90%)	⬆️

... and 43 files with indirect coverage changes

[JakobJingleheimer]

nearly there! 🙌

[JakobJingleheimer]

LGTM 😁 hopefully @bengl can confirm it does what he needs.

[Ceres6]

Can we move this forward? @JakobJingleheimer
Did you have time to check it? @bengl

[JakobJingleheimer]

It's all good from my perspective.

But Bryan would be the one to verify that it suits the need. I think I saw from him somewhere that he's been quite overwhelmed recently, which kinda means this is stuck unless we can find someone else who can verify it.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/64477/

[JakobJingleheimer]

@jsumners-nr, I think this is related to what you do IRL. Is this something you can say will or won't meet the needs of APMs?

[jsumners-nr]

@jsumners-nr, I think this is related to what you do IRL. Is this something you can say will or won't meet the needs of APMs?

Right now, what I can say is that I recall several discussions around this sort of feature in loader and/or diagnostics conversations. I cannot recall where those discussions are, or really who was participating. I think @Qard was participating and had specific ideas about how this would be useful, but I'm not 100% sure of that.

In my personal APM work, I haven't seen a need to know that it is a new thread. We just, don't deal with threads.

I'm not clear how this would solve the linked IITM issue. That issue seems rooted in ESM (like most of the issues holding that project down).

In short, this seems like a fair feature. But I don't have enough knowledge to provide the information you're looking for.

[JakobJingleheimer]

The TLDR context was that APMs need a way to know whether they're running inside the loader worker. I can't recall why they need to know that.

[jsumners-nr]

The TLDR context was that APMs need a way to know whether they're running inside the loader worker. I can't recall why they need to know that.

Yeah, me either 😢

[Qard]

That should be sufficient. Basically was just needed to logic-branch what was loaded from the library depending on if it's loaded in the app thread or the loader thread. We couldn't identify a loader thread by looking at the workerData object. (At least not reliably as the contents were unspecified.)

I'm not at Datadog anymore so might still want to poke @bengl to verify there's nothing else, but as far as I recall that was it.

[JakobJingleheimer]

Awesome, thank you!

[bengl]

LGTM, does what I need it to.

[nodejs-github-bot]

Landed in 732744c

[JakobJingleheimer]

Thanks everyone!