feat: support Atomics.waitAsync #687
Conversation
metcoder95
commented
Oct 30, 2024
•
metcoder95
commented
- feat: Support Atomics.waitAsync
Co-authored-by: Robert Nagy <ronagy@icloud.com>
… 6.12.0 (#453) Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
metcoder95
force-pushed
the
feat/async_atomics
branch
from
4b660db to
ba71411
Compare
| returning control to the main thread (avoid having open handles within a thread). If still want to have the possibility | ||
| of having open handles or handle asynchrnous tasks, you can set the environment variable `PISCINA_ENABLE_ASYNC_ATOMICS` to `1` or setting `options.atomics` to `async`. | ||
|
|
||
| > **Note**: The `async` mode comes with performance penalties and can lead to undesired behaviour if open handles are not tracked correctly. |
There was a problem hiding this comment.
Can you explain the open handle thing? Why is that an issue with async?
There was a problem hiding this comment.
Mostly as we are not doing event loop ticks, these can add some overhead if the workers start doing more than it should.
Even waiting for just the worker to wake up added some ticks that showed a difference of ±5% which is really negligible.
I've not strong opinion in this one; but if we want to make this the default behaviour we should document that it is important to not keep the workers doing too much background tasks as they can face some penalty (as well if using async, implementer needs to account for the teardown of the worker when idle, i.e. no more tasks scheduled)
There was a problem hiding this comment.
If that sounds good, I can adjust the PR for that 👍
|
I would recommend making async the default for a future semver major. IMHO it's the best balance between perf and expected behavior. |
|
Merging now, let me know if there's further feedback so I can address it in further PRs |
|
So with this change will setInterval work properly? When this PR was first brought to my attention I was concerned in part about whether something like OpenTelemetry.js would function properly in a piscina worker thread. A feature I'm thinking about creating a PR for would make piscina more attractive for beefier use cases, but the absence of ticks when no unanswered messages are in flight is problematic. |
|
Yeah; in a brief, with this change the event loop of the thread will continue ticking instead of being hold as it was before. |
|
Excellent. As an aside, I'm wondering... A couple years ago I had a process that wouldn't exit. There's a debugging library that can tell you why the event loop isn't exiting in NodeJS. I think it hooks setInterval and setTimeout so it can dump the metadata about everything that is keeping things alive. I'm wondering if it would be saner for piscina to do something similar, and keep the event loop in the workers running as long as there are outstanding intervals or timeouts. The bigger problem I'm trying to solve: What if I try to push a task that's big enough to have OpenTelemetry or Prometheus running in it into a worker thread? Its Interval will never fire and the last block of telemetry after each message will either disappear or show up potentially minutes later. Because without that, this other line of questioning (making 2 pools of workers talk to each other) is dead in the water. Because that sort of long-lived worker definitely needs to have monitoring. The flag is workable but it becomes an asterisk for things like this, and one or two are okay but beyond that I find you start to lose your audience. |
|
I believe that it should be totally doable with this new change; you can use the current alpha version for experimental testing and play with it to see how it goes. |
