-
-
Notifications
You must be signed in to change notification settings - Fork 925
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
Deadlock detection on multi thread sizedqueue access not consistent with MRI #2534
Comments
@jsvd Based on your script using RVM, I'm assuming you're using JRuby 1.7.x, but which version specifically? It probably doesn't matter too much bit it's useful |
@jsvd / @enebo - It is may be related with MRI bug which got fixed in ruby 2.5.5 with below change Jruby 9.2.6.0 still stucks with puma when such scenario occurs and in MRI its handled. refer: puma/puma#1744 |
The original report was about us not dying when there's a deadlock, which is difficult to do since we can't necessarily tell that all threads are stopped (the JVM has many threads unrelated to Ruby). It may be possible to detect that all normal Ruby threads are stopped, but since we live within the JVM they may be waiting for something happening outside JRuby; killing the process would be inappropriate in that case. Notice that even the CRuby error questions whether the "No live threads left" actually means "Deadlock". They pessimistically kill the process when they have no threads to run and they all seem to be waiting on locks. If some library or app is causing all threads to permanently block, this is a bug in that library or app. I do not consider this a bug in JRuby. The JVM itself does not error out and shut down when all threads are stopped, because it's impossible to know if something outside those threads (signal handling, object finalization, IO) might allow some thread to keep running. @anup1710 The issues you point out seem to be related to internal bugs in CRuby's Queue implementation (entirely different code than in JRuby) or issues with locks and forking, which is not supported in JRuby. Thank you for investigating! I am going to just close this since we're not planning to implement CRuby-style deadlock detection. If you want to see the deadlocked threads, you can use JVM mechanisms like capturing a thread dump (which sometimes will actually show which threads are deadlocked). |
In MRI Ruby, having 2 threads - one pulling/one pushing - acessing a SizeQueue will raise a Deadlock exception if the consumer thread dies. However, in jruby, it will hang forever:
First mri raises exception, then jruby "hangs"
Is this deliberate and a choice made on jruby side? or is it a bug?
The text was updated successfully, but these errors were encountered: