Rework raise interrupt handling at fiber edges #6538
Merged
Conversation
This file contains 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
The logic here is designed to simulate a single execution stack by forwarding any interrupt exceptions during a blocking fiber operation to the target fiber, since it is "current" and should be the one to handle any thread-level event. Originally the logic forwarded any exception received while waiting for a fiber response to the fiber and looped back to wait for a result. This had the side effect of locking both the caller and the target fibers into an endless exception-forwarding loop if the interrupt were timed such that both were in their fiber queue push/pop logic. Because both sides thought the other was the active side, the exception would be forwarded forever. The new logic will only attempt to forward an interrupt exception once, with one additional wait for a valid response or a propagated exception. If after forwarding an exception to the target fiber the caller is again interrupted, the interrupt exception at that point is either from the fiber (and should be propagated) or it is a second interrupt and a good indication that the caller needs to give up on the fiber and propagate the exception. This does open the possibility of abandoning a fiber that is still running, but that should only happen if the caller gets interrupted twice waiting on the fiber and the fiber does not respond after the first interrupt. See jruby#6309
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
The logic here is designed to simulate a single execution stack by
forwarding any interrupt exceptions during a blocking fiber
operation to the target fiber, since it is "current" and should be
the one to handle any thread-level event. Originally the logic
forwarded any exception received while waiting for a fiber
response to the fiber and looped back to wait for a result. This
had the side effect of locking both the caller and the target
fibers into an endless exception-forwarding loop if the interrupt
were timed such that both were in their fiber queue push/pop
logic. Because both sides thought the other was the active side,
the exception would be forwarded forever.
The new logic will only attempt to forward an interrupt exception
once, with one additional wait for a valid response or a
propagated exception. If after forwarding an exception to the
target fiber the caller is again interrupted, the interrupt
exception at that point is either from the fiber (and should be
propagated) or it is a second interrupt and a good indication that
the caller needs to give up on the fiber and propagate the
exception.
This does open the possibility of abandoning a fiber that is still
running, but that should only happen if the caller gets
interrupted twice waiting on the fiber and the fiber does not
respond after the first interrupt.
See #6309