Bug #7560

Process.kill incurs 100ms cost when threads exist

Added by Aman Gupta over 1 year ago. Updated over 1 year ago.

[ruby-core:50897]
Status:Closed
Priority:Normal
Assignee:Nobuyoshi Nakada
Category:-
Target version:-
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 1 year ago

  • signal.c (rbfkill): remove rbthreadpolling() 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, rbthreadpolling() doesn't make sense anyway. When rbthreadalone() 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 1 year 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 (rbfkill): remove rbthreadpolling() 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, rbthreadpolling() doesn't make sense anyway. When rbthreadalone() 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 1 year 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 rbthreadpolling().

That said, I do not understand why rbthreadpolling() 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 1 year ago

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

Also available in: Atom PDF