You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
@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 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?
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.
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.
Activity
addaleax commentedon May 6, 2022
@syg I am personally fine with anything here.
--trace-atomics-waithas 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 commentedon May 6, 2022
Given the current functionality of
--trace-atomics-waittracing theAtomics.waitevents (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 commentedon May 6, 2022
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.doc,worker: deprecate --trace-atomics-wait
kvakil commentedon Aug 2, 2022
I created #44093 to start the deprecation process & for further discussion.
doc,worker: deprecate `--trace-atomics-wait`
doc,worker: deprecate `--trace-atomics-wait`
doc,worker: deprecate `--trace-atomics-wait`
doc,worker: deprecate `--trace-atomics-wait`
6 remaining items
github-actions commentedon Aug 3, 2023
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 commentedon Aug 3, 2023
We should probably runtime deprecate it to move forward with this.
marco-ippolito commentedon Dec 16, 2023
Moving to runtime deprecation with #51179
doc: runtime deprecate flag --trace-atomics-wait
marco-ippolito commentedon Dec 22, 2023
@syg the flag has moved to runtime deprecation, afaik it will be released in the next major (22).
marco-ippolito commentedon Apr 29, 2024
After this PR: #52747 it will be completely removed
cli: move --trace-atomics-wait to eol
cli: move --trace-atomics-wait to eol