Bug #7560: Process.kill incurs 100ms cost when threads exist

• Status: Closed
• Assignee: nobu (Nobuyoshi Nakada)
• Target version: -
• ruby -v: ruby 2.0.0dev (2012-12-14 trunk 38379) [x86_64-darwin12.2.0]

[tmm1 (Aman Karmani)]

% ruby -rbenchmark -e' puts Benchmark.measure{ Process.kill(0, Process.pid) } '
0.000000 0.000000 0.000000 ( 0.000011)

% ruby -rbenchmark -e' Thread.new{sleep}; puts Benchmark.measure{ Process.kill(0, Process.pid) } '
0.000000 0.000000 0.000000 ( 0.101127)

[kosaki (Motohiro KOSAKI)]

• Status changed from Open to Closed
• % Done changed from 0 to 100

This issue was solved with changeset r38380.
Aman, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

---

• signal.c (rb_f_kill): remove rb_thread_polling() because this
  has no good effect and makes meaningless 100ms delay. 1)
  when sending signal to another process, waiting has just silly.
  2) when sending signal to current process, 100ms is often not
  enough time to wait. It depend on kernel behavior. And,
  rb_thread_polling() doesn't make sense anyway. When rb_thread_alone()
  is true, it doesn't wait at all and Process.kill() users don't
  expect threading changes Process.kill() behavior. [Bug #7560]

[normalperson (Eric Wong)]

"tmm1 (Aman Gupta)" [e-mail] wrote:

Issue #7560 has been reported by tmm1 (Aman Gupta).

---

Bug #7560: Process.kill incurs 100ms cost when threads exist
https://bugs.ruby-lang.org/issues/7560

Author: tmm1 (Aman Gupta)
Status: Open
Priority: Normal
Assignee: nobu (Nobuyoshi Nakada)
Category:
Target version:
ruby -v: ruby 2.0.0dev (2012-12-14 trunk 38379) [x86_64-darwin12.2.0]

% ruby -rbenchmark -e' puts Benchmark.measure{ Process.kill(0, Process.pid) } '
0.000000 0.000000 0.000000 ( 0.000011)

% ruby -rbenchmark -e' Thread.new{sleep}; puts Benchmark.measure{ Process.kill(0, Process.pid) } '
0.000000 0.000000 0.000000 ( 0.101127)

This is the call to rb_thread_polling().

That said, I do not understand why rb_thread_polling() exists.

It was probably only for green threads in 1.8 and got carried over.
If so, I think all calls to it can be removed and the function can
be made a no-op.

kosaki/ko1: what do you guys think?

[kosaki (Motohiro KOSAKI)]

@normalperson (Eric Wong): I agree. I removed rb_thread_polling() today then. :)