This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [PATCH][RFA] Reap children on stack trace generation.
- From: David Daney <ddaney at avtrex dot com>
- To: tromey at redhat dot com
- Cc: java-patches at gcc dot gnu dot org
- Date: Fri, 09 Jul 2004 10:43:51 -0700
- Subject: Re: [PATCH][RFA] Reap children on stack trace generation.
- References: <40EA537F.5080005@avtrex.com> <87y8ltcdzo.fsf@fleche.redhat.com>
Tom Tromey wrote:
>>>>>>"David" == David Daney <ddaney@avtrex.com> writes:
>
>
> David> natPosixProcess.cc has a related problem. First it forks, but if the
> David> exec fails, the child is not reaped.
>
> If the exec fails, do we really need the kill()?
In theory no. In practice probably not. But the potential for blocking
because I overlooked something scares me. So I put in the kill.
If you want it removed, I will do it.
>
> Otherwise this is looking good. But also see
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11801
> The thing is, even with this patch we need a fix for the case where
> the user just expects the process to be GCd and reaped without an
> explicit waitFor call.
I agree.
I have worked around 11801 in my applications. The workaround is to
always do a waitFor() from the same thread that did the Runtime.exec().
The patch to natPosixProcess.cc is needed in any event.
It seems to me that the patch to NameFinder.java would not strictly
speaking be needed if 11801 were fixed. However it is still a win on
systems where 11801 is not a problem as you still have to wait for a GC
cycle and then for the finalizers to be run before the zombies would be
reaped.
I have the time to check in this patch. Fixing 11801 is not in my
immediate plans
David Daney.