This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH][RFA] Reap children on stack trace generation.


David Daney wrote:
> Tom Tromey wrote:
> 
>>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.
> 

This is more complicated than I thought.  Most of the above is a bunch
of lies and half-truths...

Here are the things I know about how Processes should work:

1) You cannot kill the child process when the Process instance is
GCed/finalized because it must be keep running.  From Sun's
documentation for Process:  The subprocess is not killed when there are
no more references to the Process object, but rather the subprocess
continues executing asynchronously.

2) We don't want to leave zombies laying around.

3) If the sub-process exits and we have no more references to the
Process object, we don't want to leak resources.

Fixing 11801 means that the points above are satisfied.

I think that even on NPTL based systems that there are problems with the
current implementation of PosixProcess.  So what we really need is a
rewrite of PosixProcess, not just a few random patches.

We probably need a separate thread that only waits for the children.  It
might be possible to use a SIGCHLD handler, but I am not sure about this
as there might be synchronization issues.

However if PosixProcess were fixed, my patches to NameFinder would be
redundant.

David Daney


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]