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

Issue #10231 has been updated by Eric Wong.


 [e-mail] wrote:
 > 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.
 
 Right.  The problem I want to solve is when independently-maintained
 pieces of code have conflicting calls to waitpid:
 
 	th = Thread.new { Process.waitpid(-1) }
 
 	p Process.waitpid(fork {})
 	p th.value
 
 The above behaves inconsistently depending on scheduling.  Presumably
 the thread waiting on a single pid should beat the thread waiting on all
 threads.  And it may not be solvable for waiting on process groups...
 
 So the above combination of waitpid calls is likely broken no matter
 what.

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

* 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/