From: "ko1 (Koichi Sasada)" <redmine@...>
Date: 2013-08-29T19:07:33+09:00
Subject: [ruby-core:56862] [ruby-trunk - Feature #8823][Feedback] Run trap	handler in an independent thread called "Signal thread"


Issue #8823 has been updated by ko1 (Koichi Sasada).

Status changed from Open to Feedback

After discussion, I decide to reject this feature.

How about to permit Queue operation in trap handler with [ruby-trunk - Feature #3620], and use Queue#push to synchronize/communicate between other threads. This is Ruby-level alternative  of pipe hack.

Comments are welcome.

----------------------------------------
Feature #8823: Run trap handler in an independent thread called "Signal thread"
https://bugs.ruby-lang.org/issues/8823#change-41409

Author: ko1 (Koichi Sasada)
Status: Feedback
Priority: Normal
Assignee: ko1 (Koichi Sasada)
Category: core
Target version: current: 2.1.0


= Abstract

How about to make an "Signal thread" to run trap handler?

= Problem

Now, all of thread synchronization methods are not permitted because there is a possibility of deadlock between trap handler and main thraed.

For example:

  m = Mutex.new
  trap(:INT){
    m.synchronization{...}
  }
  m.synchronization{
    ...
    ... # recv SIGINT, and invoke trap handler
    ...
  }

In this case, trap handler (a block passed to trap method) is run on the main thread.

= Proposal

Make a signal handler independent from main thread. If main thread and trap handler run in different threads, there are no such problem.

= Implementation

Don't create signal handler at first. But the first time we need a signal handler, signal handler is created by main thread.

See timing chart (PDF) I attached.

= Discussion

== Advantage:
* Signal thread is independent on main thread, this means that you can use thread synchronization between trap handler and main thread. In other words, you can run any program in trap handler.
* Simplify a path from sighandler to trap invocation thread (after creation of a signal thread)
* Doesn���t need a difficult implementation (modify is limited).

== Disadvantage:
* There is a small compatibility issue because ���Thread.current��� on a trap handler is not a main thread.

== Other Discussion:
* Create signal thread at first like timer thread is high cost. Without `trap���, we don���t need a signal thread any more.
* In signal handler and timer thread, we can���t make a signal thread because creating ���Ruby thread��� (== signal thread) needs GVL. So the process path from timer thread to main thread is remained.

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




-- 
http://bugs.ruby-lang.org/