ProcessReaper: single thread reaper

[roger riggs]

Hi Peter,

On a related topic, the request to be able to destroy a Process and all 
of its children
might also want to used the group pid to be able to identify all of the 
children.

Roger


On 4/9/2014 2:08 AM, Peter Levart wrote:
> Hi Martin,
>
> As you might have seen in my later reply to Roger, there's still hope 
> on that front: setpgid() + wait(-pgid, ...) might be the answer. I'm 
> exploring in that direction. Shells are doing it, so why can't JDK?
>
> It's a little trickier for Process API, since I imagine that shells 
> form a group of processes from a pipeline which is known in-advance 
> while Process API will have to add processes to the live group 
> dynamically. So some races will have to be resolved, but I think it's 
> doable.
>
> Stay tuned.
>
> Regards, Peter
>
> On 04/08/2014 07:48 PM, Martin Buchholz wrote:
>> Peter, thank you very much for your deep analysis.
>>
>> TIL and am horrified: signals on Unix are not queued, not even if you 
>> specify SA_SIGINFO.  Providing siginfo turns signals into proper 
>> "messages" each with unique content, and it is unacceptable to simply 
>> drop some (Especially when proper queueing seems required for 
>> so-called real-time signals), but at least the Linux kernel does so 
>> very deliberately.   45 years later, we are still fighting with 
>> unreliable Unix signals...
>>
>> We can't call waitpid(WAIT_ANY, ) because we can only wait for 
>> processes owned by the j.l.Process subsystem.  We can't override libc 
>> functions like waitpid because the JVM may be a "guest" in some other 
>> process.
>>
>> I don't know of any public examples, but it is reasonable to add a 
>> JVM to a previously pure native code application, similarly to the 
>> way tcl or lua is often used to provide a higher-level safer 
>> programming api to native code, and some programs at Google use this 
>> strategy.
>>
>> What problem are we actually trying to solve?  The army of reaper 
>> threads is ugly, but the inefficiency is greatly mitigated by the use 
>> of small explicit stack sizes.  Redoing the process code is always 
>> risky, as we have already seen in this thread.
>>
>> Maintaining a single child helper process which spawns all the 
>> (grand)child processes seems reasonable, although it would create a 
>> permanent intermediate entry in the process table (pstree?) which 
>> might confuse some sysadmin scripts.  Is it worth it?
>>
>