ko1 / atdot.net wrote:
> Good point. Seems good. Thank you!

OK, commited as r64062

> BTW, I forget that why the trap handler is limited to main thread.

I can think of at least three reasons:

1) Similar to this bug: other threads may exit soon,
   main thread is long-lived so interrupt won't get lost

2) Typical trap handlers are established at program startup,
   before other threads exist, so maybe some are reliant on
   Thread.current[] values inside trap (perhaps unknowingly
   through libraries).

3) Concurrency problem.  Mutex isn't usable inside trap,
   but there may be instances of reentrancy-safe code which
   can't be made thread-safe.

> Can we relax this limitation?

I don't think it's necessary; anybody who relies on trap will
likely structure main thread to deal with it (e.g. not block on
slow NFS IO#read :P).  We can workaround 1), but I expect
compatibility and safety problems from 2) and 3).

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>