Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

thread rescue & ensure behaviour #5669

colinsurprenant opened this Issue Mar 28, 2019 · 2 comments


None yet
3 participants
Copy link

colinsurprenant commented Mar 28, 2019

I'd like to raise awareness about some findings I did in different behaviours of threads rescue and ensure blocks across different JRuby versions (also tested on MRI).

In a nutshell, embedded thread with their main blocks wrapped in a begin/rescue/ensure and the innermost thread raising an exception shows different execution flow across JRuby versions. It is not clear to me what should be expected and considered a correct flow.

I created an investigation issue in logstash elastic/logstash#10612 about this, let me know if you'd like me to bring it all here if this is deemed worthy of more investigation and followup over here.


This comment has been minimized.

Copy link

kares commented Apr 2, 2019

nice to see 9.2 improve over 9.1 ... we did some thread (status) related fixes around that in 9.2.6
... JRuby still isn't matching the interrupt logic but we should be able to get it even closer to MRIs

also to be noted, this likely does not matter at all here since you demonstrated the diff without explicit locking, JRuby does not allow thread interrupts (from mutex-es) compared to MRI esp. due LS: #4261


This comment has been minimized.

Copy link

headius commented Apr 9, 2019

@colinsurprenant The big question for me is whether the CRuby behavior is expected. JRuby is at least consistent in both cases, though different than what CRuby does.

I believe part of the problem here is the scheduling of the threads. If the thread errors out on its own before calling join, and abort_on_exception=true as here, the exception is re-raised on the main thread. This could happen at any level here, though the sleep does at least help ensure it's not the innermost thread. I think if there's a thread waiting on join, the aborted exception is not re-raised on main, but I need to confirm that. In any case, there's different exception logic inside join, which could change behavior based on the timing of the thread completion.

Basically I think we have a race between abort_on_exception and join and that's causing some odd behavior in the rescues and ensures.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.