You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are two tests in MRI that test whether a Thread can be joined from a Signal trap handler. Both tend to fail intermittently on JRuby (the INT trap fails to capture the event), likely because of some race between setting up the signal handler and initiating the interrupt.
Because these are very peculiar cases, and test behavior specific to MRI's VM (thread state and signal handlers did not mix) I'm excluding these cases from our run.
The text was updated successfully, but these errors were encountered:
I am not convinced the intermittent failures here indicate an
issue in JRuby. Rather, I suspect there's a race, since these
tests involve setting up a signal handler, signalling INT from a
thread, and joining in both main and the handler itself. However
I have been unable to come up a reason for the race, so I have
filed #4956 to track this exclusion.
An example script, which should run forever but dies:
```ruby
loop {
Signal.trap(:INT, "DEFAULT")
t0 = Thread.current
t = Thread.new {Thread.pass until t0.stop?; Process.kill(:INT, $$)}
Signal.trap :INT do
t.join
end
t.join
print '.'
}
```
There are two tests in MRI that test whether a Thread can be joined from a Signal trap handler. Both tend to fail intermittently on JRuby (the INT trap fails to capture the event), likely because of some race between setting up the signal handler and initiating the interrupt.
Because these are very peculiar cases, and test behavior specific to MRI's VM (thread state and signal handlers did not mix) I'm excluding these cases from our run.
The text was updated successfully, but these errors were encountered: