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

Issue #10231 has been updated by Charles Nutter.


Eric Wong wrote:
>  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.

Yeah, I don't think there's a solution for that unless you pipe ALL waitpid calls through the same logic that waits on first caller for that pid...and then there's process groups, as you say.

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

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