[ruby-core:65049] [ruby-trunk - Bug #10231] Process.detach(pid) defines new singleton classes every call

Issue #10231 has been updated by Charles Nutter.


Eric Wong wrote:
>  I prefer deliberately leaving out Process::Waiter and Thread references,
>  since I think we may be able to avoid Thread creation entirely in the
>  future (not sure if it's worth the effort).

FWIW, JVM always does a waiter thread to avoid multiple calls to waitpid (which as you know returns results exactly once). The waiter thread is not unusual in that regard.

It's probably possible to avoid the thread and make concurrent waiters just wait on a mutex too...

def wait_for_process
  @mutex.lock
  @result ||= waitpid
ensure
  @mutex.unlock
end

Not sure what wrenches this throws into UNIX-style process management, though.

Note that JVM's subprocess logic also has threads draining the child's streams into an in-memory buffer. I do NOT recommend that. In JRuby 9k we no longer use the JVM's subprocess logic.

----------------------------------------
Bug #10231: Process.detach(pid) defines new singleton classes every call
https://bugs.ruby-lang.org/issues/10231#change-48920

* Author: Charles Nutter
* Status: Closed
* Priority: Normal
* Assignee: Eric Wong
* Category: core
* Target version: current: 2.2.0
* ruby -v: Any version with Process.detach
* Backport: 2.0.0: UNKNOWN, 2.1: UNKNOWN
----------------------------------------
The logic for Process.detach(pid) adds a singleton "pid" method to the thread it returns for every call. This is bad for method caches (MRI still flushes them all for this, I believe) and memory churn (singleton classes are not small).

The offending line of code is here: https://github.com/ruby/ruby/blob/trunk/process.c#L1041

I would suggest that Process.detach should return a subclass of Thread that has the pid method defined ahead of time.

It also stores the value in thread local storage, rather than as an instance variable. I'm not sure why.



-- 
https://bugs.ruby-lang.org/