ProcessReaper: single thread reaper
roger riggs
roger.riggs at oracle.com
Wed Apr 9 13:20:22 UTC 2014
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?
>>
>
More information about the core-libs-dev
mailing list