From: Eric Wong <normalperson@...>
Date: 2013-08-27T19:36:06+00:00
Subject: [ruby-core:56836] Re: [ruby-trunk - Feature #8823][Open] Run trap handler in an independent thread called "Signal thread"

"ko1 (Koichi Sasada)" <redmine@ruby-lang.org> wrote:
> == Disadvantage:
> * There is a small compatibility issue because ���Thread.current��� on a
> trap handler is not a main thread.

This adds race conditions in existing code.

There is no easy way for existing code to be safe with both your
proposed implementation and the current trap implementation.
I can't safely add mutex.synchronize{} in existing trap handler.

Perhaps this version should be something like:

	trap_with_thread(:INT) { ... }

> == Other thought
> 
> I know a philosophy that `trap' should run only a tiny program,
> without synchronization and so on. I agree with this philosophy.
> Current behaveour which prohibits synchronization features helps this
> philosophy. But I'm not sure which is good way for Ruby.

Alternatively, queue trap handler execution in VM and make them
uninterruptible (at Ruby-level) when running.  This is less
likely incompatible, but can slow down execution of (crazy) apps
which disagree with this philosophy and do too much in trap.