Bug #7560

Process.kill incurs 100ms cost when threads exist

Added by Aman Gupta over 2 years ago. Updated over 2 years ago.

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

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 Magnifier (233 Bytes) Aman Gupta, 12/14/2012 10:22 PM

Associated revisions

Revision 38380
Added by Motohiro KOSAKI over 2 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 Motohiro KOSAKI over 2 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 Motohiro KOSAKI over 2 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 Updated by Eric Wong over 2 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 Updated by Motohiro KOSAKI over 2 years ago

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

Also available in: Atom PDF