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
Timeout::timeout not throwing exception when timeout period reaches #1050
Comments
This is a known limitation with JRuby subprocess launching right now. The process management on JVM does not allow cleanly interrupting a blocking IO read of the subprocess, and as a result we can't cause it to timeout. We plan to fix this by implementing our own subprocess logic, but unfortunately for now this is a limitation. |
@headius Thanks. I'd like to work on this. Do you have some blueprint/wiki which explains what needs to be done for this feature? |
We have a number of folks interested...the key task is to start getting an FFI or jnr-ffi (our Java equivalent) version of process launching to do everything Ruby wants. See projects like posix_spawn for examples. |
FWIW, I've reproduced that this is still the case with JRuby 9.0.0.0 whereas MRI 2.1.5 puts "inside rescue" |
I faced the same issue when I tried to do something like this in
|
I suspect MRI is using a non-blocking form of wait here, that allows them to give up on the subprocess. I will look into whether we can do the same. |
After looking into this I think the cleanest we could support interruptible |
I used somewhat of a similar approach here as a work-around. I called I don’t know the merits or de-merits of the suggested approach but at-least JRuby provides a way to implement this. I use caution using |
So it turns out that the JVM also uses |
@Adithya-copart Yes, that works...or if you can afford to do some polling with a timeout, you can I will push a PR you can play with. |
This addresses jruby#1050 in the same way CRuby implements this. In CRuby, the wait functions are called directly, and the `pthread_kill` function is used to force the call to be interrupted. It turns out the JVM also uses `pthread_kill` to interrupt blocking native calls, so we use the same binding they do. Note that this will only be used on non-Windows, but the JDK's binding of `NativeThread.signal` might already be stubbed out there.
I've pushed #5848, which wraps the This is not tied into backticks, so it does not yet fix the original reported issue. |
This addresses jruby#1050 in the same way CRuby implements this. In CRuby, the wait functions are called directly, and the `pthread_kill` function is used to force the call to be interrupted. It turns out the JVM also uses `pthread_kill` to interrupt blocking native calls, so we use the same binding they do. Note that this will only be used on non-Windows, but the JDK's binding of `NativeThread.signal` might already be stubbed out there.
Fixed by #5848. |
/tmp/loop.sh
Now start the above script from a Ruby script.
/tmp/test.rb
Execute the above script in a JRuby
ScriptingContainer
.The rescue block is not getting executed. Tested this with MRI and it works well there.
The text was updated successfully, but these errors were encountered: