Project

General

Profile

Misc #15510

Easter egg in Thread.handle_interrupt

Added by larskanis (Lars Kanis) 11 months ago. Updated 11 months ago.

Status:
Open
Priority:
Normal
Assignee:
-
[ruby-core:90903]

Description

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 Object as 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:

  1. Make non-exceptions an ruby implementation specific feature, adjusts current tests and optionally add tests which are tagged as implementation specific.
  2. Document it officially, but choose some more meaningful class names instead of Integer

History

Updated by Eregon (Benoit Daloze) 11 months 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!

Also available in: Atom PDF