Fix suspend_process() issue on processes in dirty schedulers #10241
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
CT Test Results 3 files 142 suites 50m 22s ⏱️ Results for commit 410680d. ♻️ This comment has been updated with latest results. To speed up review, make sure that you have read Contributing to Erlang/OTP and that all checks pass. See the TESTING and DEVELOPMENT HowTo guides for details about how to run test locally. Artifacts// Erlang/OTP Github Action Bot |
# Context
`erlang:suspend_process()` was broken when applied on processes that
happened to be in a dirty-scheduler. The symptom was:
- `internal_error` would be returned when called synchronously
- `not_suspended` would be delivered when called asynchronously,
even though the process was in fact suspended
# Problem
When trying to suspend a processes in a dirty-scheduler, it is actually
the dirty-scheduler who suspends the process, by calling
`erts_proc_sig_handle_pending_suspend()`. This essentially activates all
pending suspend monitors and finally sends all pending sync messages, by
calling `sync_suspend_reply()`.
The problem is that when calling the latter, it is passing the process
state *before* activating the monitors. In particular, the SUSPENDED
flag is not set, what makes `sync_suspend_reply()` assume that something
is wrong.
b91bf2b to
c7897c6
Compare
|
Thanks! I've rebased the fix onto OTP 26.2.5 (so we can patch this) and added a test case and force pushed the fix. |
c7897c6 to
410680d
Compare
rickard-green
approved these changes
Oct 3, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Context
erlang:suspend_process()was broken when applied on processes that happened to be in a dirty-scheduler. The symptom was:internal_errorwould be returned when called synchronouslynot_suspendedwould be delivered when called asynchronously, even though the process was in fact suspendedProblem
When trying to suspend a processes in a dirty-scheduler, it is actually the dirty-scheduler who suspends the process, by calling
erts_proc_sig_handle_pending_suspend(). This essentially activates all pending suspend monitors and finally sends all pending sync messages, by callingsync_suspend_reply().The problem is that when calling the latter, it is passing the process state before activating the monitors. In particular, the SUSPENDED flag is not set, what makes
sync_suspend_reply()assume that something is wrong.