Project

General

Profile

Bug #7560

Process.kill incurs 100ms cost when threads exist

Added by tmm1 (Aman Gupta) almost 5 years ago. Updated almost 5 years ago.

Status:
Closed
Priority:
Normal
Target version:
-
ruby -v:
ruby 2.0.0dev (2012-12-14 trunk 38379) [x86_64-darwin12.2.0]
[ruby-core:50897]

Description

% 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)

process_kill.patch (233 Bytes) process_kill.patch tmm1 (Aman Gupta), 12/14/2012 10:22 PM

Associated revisions

Revision 38380
Added by kosaki (Motohiro KOSAKI) almost 5 years ago

  • 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]

Revision 38380
Added by kosaki (Motohiro KOSAKI) almost 5 years ago

  • 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]

Revision 38380
Added by kosaki (Motohiro KOSAKI) almost 5 years ago

  • 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]

Revision 38380
Added by kosaki (Motohiro KOSAKI) almost 5 years ago

  • 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]

History

#1 Updated by kosaki (Motohiro KOSAKI) almost 5 years ago

  • 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]

#2 [ruby-core:50899] Updated by normalperson (Eric Wong) almost 5 years ago

"tmm1 (Aman Gupta)" ruby@tmm1.net 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?

#3 [ruby-core:50901] Updated by kosaki (Motohiro KOSAKI) almost 5 years ago

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

Also available in: Atom PDF