"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.