Easter egg in Thread.handle_interrupt
The docs of
Thread.handle_interrupt are quite clear about the argument to be passed. It must be a hash of
ExceptionClass => :TimingSymbol pairs. I never thought that anything other than a
Exception derivation would be accepted.
But then I read the tests to this method and wondered: Some of the tests set
ExceptionClass. Moreover the method is not covered by ruby-spec and JRuby excludes several failing tests.
So I inspected the code and found some obscure behavior: There are actually two non-exceptions which can be masked by
Thread.handle_interrupt(Integer => :TimingSymbol). It is main thread termination and
Thread#kill. Now this blur sentence in the docs makes some more sense:
interrupt means asynchronous event and corresponding procedure by Thread#raise, Thread#kill, signal trap (not supported yet) and main thread termination (if main thread terminates, then all other thread will be killed).
So they are implemented as integers internally. However IMHO
Thread.handle_interrupt(Integer => :TimingSymbol) is ... ugly.
Some proposals are:
- Make non-exceptions an ruby implementation specific feature, adjusts current tests and optionally add tests which are tagged as implementation specific.
- Document it officially, but choose some more meaningful class names instead of
Updated by Eregon (Benoit Daloze) over 4 years ago
Integer sure feels like a hack, but using
Thread.handle_interrupt(Object => :TimingSymbol) makes some sense, and I think we should document that as a way to also ignore those interrupts.
I'm against 1) (no need to be implementation-specific here), and I think 2) with
Object or a variant (e.g., a Symbol :all) would be good.
Specs for Thread.handle_interrupt would be nice to have in ruby/spec, contributions welcome!