Can --trace-atomics-wait be removed

[syg]

What is the problem this feature will solve?

The V8 API hook (SetAtomicsWaitCallback) to support --trace-atomics-wait is fairly complex and adds maintenance burden. Further the only user of the API is node, and node only uses a subset of the functionality, and only for diagnostic purposes.

Is it feasible to remove this diagnostic functionality? Judging by the original commit message the original motivation was maybe to use the hooks to build a deadlock detection system, not just printf diagnostics. It's been 4 years since then, and if no such system has been prototyped and it's not on the roadmap anytime soon, I'd like to deprecate and remove the V8 API.

cc @addaleax

What is the feature you are proposing to solve the problem?

Remove --trace-atomics-wait

What alternatives have you considered?

No response

[addaleax]

@syg I am personally fine with anything here. --trace-atomics-wait has been useful for me in the past occasionally, and the thing about it is that it’s useful specifically in situations in which it can be hard to debug with other tools, but if you feel that it’s not worth it, sure, drop it.

[syg]

@syg I am personally fine with anything here. --trace-atomics-wait has been useful for me in the past occasionally, and the thing about it is that it’s useful specifically in situations in which it can be hard to debug with other tools, but if you feel that it’s not worth it, sure, drop it.

Given the current functionality of --trace-atomics-wait tracing the Atomics.wait events (not using the handle to interrupt waits), is it possible to do that in userland? I guess the problem is that on a failure to wait, regardless of whether you re-read the address after the fact or buffer the address beforehand, there's still no guarantee if that value is what caused it to fail?

[syg]

Another option here is to keep the pre-hook needed for --trace-atomics-wait, remove the other hooks, as well as the handle. The handle is probably 70% of the complexity I want to remove.

[kvakil]

I created https://github.com/nodejs/node/pull/44093 to start the deprecation process & for further discussion.

[github-actions[bot]]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[github-actions[bot]]

There has been no activity on this feature request for 5 months and it is unlikely to be implemented. It will be closed 6 months after the last non-automated comment.

For more information on how the project manages feature requests, please consult the feature request management document.

[aduh95]

We should probably runtime deprecate it to move forward with this.

[marco-ippolito]

Moving to runtime deprecation with https://github.com/nodejs/node/pull/51179

[marco-ippolito]

@syg the flag has moved to runtime deprecation, afaik it will be released in the next major (22).

[marco-ippolito]

After this PR: https://github.com/nodejs/node/pull/52747 it will be completely removed