Project

General

Profile

Actions

Feature #8823

closed

Run trap handler in an independent thread called "Signal thread"

Added by ko1 (Koichi Sasada) over 10 years ago. Updated over 10 years ago.

Status:
Rejected
Target version:
[ruby-core:56824]

Description

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


Files

data-signal.pdf (179 KB) data-signal.pdf ko1 (Koichi Sasada), 08/27/2013 08:13 PM
data-signal-2.pdf (186 KB) data-signal-2.pdf ko1 (Koichi Sasada), 08/27/2013 08:52 PM
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0