`Concurrent::Promises::Future#value!` can return `nil` even when promise is not resolved yet about concurrent-ruby HOT 6 CLOSED

Thanks for the report.
That's very surprising, as Signal.trap("INT") {} should mean sending SIGINT should do nothing.

But actually with a little debugging what happens is ConditionVariable#wait has a spurious wakeup on CRuby (.wait returns even though neither .broadcast nor .signal has been called) in that case, probably because CRuby does SIGVTALRM/interrupt logic anyway it seems, even with the trap overridden.
Although even though the trap is overridden, it still has to execute that empty block on the main thread, so that's probably why we get that internal interrupt.
That's maybe a CRuby issue, because for instance there is no such issue on TruffleRuby.

We can workaround in

from concurrent-ruby.

I reviewed all usages of ConditionVariable#wait in concurrent-ruby, they seem all fine.
In addition to #1016 there was also #1017 and #1018.
But as can be seen in #1017 sometimes it should not be a loop directly around the .wait.
So given we need the code only in one place it feels like the class is not necessary.
BTW, there is already

from concurrent-ruby.

To reproduce:

# test.rb
require "concurrent-ruby"

Signal.trap("INT") {}

task = Concurrent::Promises.future do
  i = 0
  loop do
    i = (i + 1) % 10
  end
  i
end

puts task.value!
puts "Unexpected behaviour?" if task.pending?

Run in console:

❯ ruby ./test.rb
^C
Unexpected behaviour?

from concurrent-ruby.

CRuby issue for this: https://bugs.ruby-lang.org/issues/20047

from concurrent-ruby.

Fix in #1016

from concurrent-ruby.

@eregon what are you thoughts about making a private/internal class like ReliableConditionVariable that would wrap the loop/timeout fix for CRuby, or defer to the language recommendation? I wonder how many places this pattern should be duplicated... though hopefully a fix gets some traction in upstream CRuby too.

from concurrent-ruby.