Align Java Executor Service behavior for shuttingdown?, shutdown?

[bensheldon]

Fixes #1041

• shuttingdown? now uses isShutdown && !isTerminated
• shutdown? now accurately represents when all tasks have terminated
• kill now waits for all tasks to terminate (it waits indefinitely; I'm not sure if it's possible for that to hang on Java) Extracted #kill change to ThreadPoolExecutor#kill will wait_for_termination in JRuby; ensure TimerSet timer thread shuts down cleanly #1044

[bensheldon]

1. Something in here is causing a deadlock on JRuby in the TimerSet tests (I'm guessing it's the wait_for_termination)
2. We need a maximum Actions workflow timeout of not 6 hours.

[eregon]

Could you make a PR to add timeouts of 10 minutes (which looks enough from looking at previous runs) for all CI workflows?

[eregon]

Can you reproduce the issue locally with TimerSet on JRuby?
I guess it might be related to that kill change.
So it might be worth to extract that change to a separate PR.
In general I wonder if it's really worth the trouble & complexity of having different implementations for JRuby when there is already a pure-Ruby implementation of some concurrent-ruby class.

[bensheldon]

@eregon Thank you for the help! 🙇🏻

• Extracted kill to Align Java Executor Service behavior for shuttingdown?, shutdown? #1042
• Added GitHub actions timeout in Add 10 minute timeout to GitHub Actions #1043

In general I wonder if it's really worth the trouble & complexity of having different implementations for JRuby when there is already a pure-Ruby implementation of some concurrent-ruby class.

I feel mixed. A lot of Concurrent Ruby is inspired by Java objects, so it seems like it would be better (simpler? more performant? less potential for bikeshedding or 2nd-systeming them?) to lightly wrap them rather than use a Ruby implementation. I have similar vague feelings about Native C Extensions too; which to chit-chat also makes me wonder if YJIT would make that less worthwhile.

[eregon]

I have similar vague feelings about Native C Extensions too; which to chit-chat also makes me wonder if YJIT would make that less worthwhile.

The concurrent-ruby C ext is only for atomic variables.
Those are likely quite a bit faster than using a Mutex.
There are some benchmarks for this: e.g. https://github.com/ruby-concurrency/concurrent-ruby/blob/master/examples/benchmark_atomic.rb