ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: [PATCH] Asynchronous execution of processes
Date Tue, 13 Nov 2001 13:19:00 GMT
From: "Stefan Bodewig" <>

> On Fri, 9 Nov 2001, Jose Alberto Fernandez <>
> wrote:
> > There are two issues here, first what to do with IO if not
> > redirected;
> force it to /dev/null or NUL: or whatever - you cannot expect that a
> detached process and Ant share the same IO streams IMHO.

Well remember that in Ken escenario which was the one I used as the basis
for the behaviour, the asynchonous process is *supposed* to finish before the
VM ends, so things like being able to look at the IO being producced are fine.

I have no problem with allowing redirection to a file (or nul ) as an option
but I do not thing we should force such things.

> > and second what does each OS does when the VM that spawn the process
> > ends.
> Using the attached class (DetachedExec), which is a very much stripped
> down version of your patch I get more or less random behavior on my
> RedHat 7.2 box:
> Using JDK 1.1.8 will never start the xterm - seems the VM terminates
> before the exec can happen.
> Using JDK 1.3.1 (Sun) it started xterm (and never terminated it) in
> eight out of ten attempts, once didn't start it and once terminated
> the VM with 
> ****************
> Another exception has been detected while we were handling last error.
> Dumping information about last error:
> PC                = 0x0x4018b8c9
> SIGNAL            = 11
> LIBRARY NAME      = (N/A)
> Please check ERROR REPORT FILE for further information, if there is any.
> Good bye.
> Using JDK 1.4beta3 it started xterm (and kept it running) in five out
> of ten attempts and didn't start xterm at all in the other five cases.
> Seems there is no reliable behavior.

What happens if you use all the threads management like does?
If you look at the patch, you will see that the process creation and lots of the 
other settings are performed outside of the deamon thread. It is only the
process waitfor part and its surroundings that are done asynchronously.

I think that this should provide for a more consistent behavior.

> The second version (DetachedExec2), which is the platform dependent
> solution, always started xterm, but with some interesting (and at
> least to me) unexpected results:
> JDK 1.1.8 will start xterm but not terminate Java before I close the
> xterm, so it is not detached at all.
> JDK 1.3.1 works as I'd expect it, it always starts xterm and
> terminates the VM.
> JDK 1.4beta3 works close to what I'd expect, it always starts xterm
> and hands back control to the shell that launched Java - but a java
> process keeps running, even after I close the xterm.  The process
> doesn't respond to signals and needs to be killed using the TERM
> signal.  I'd call that a bug in the VM.

Is it a "zombie" process by any chance? In unix when child process
are still running, the parent process must continue to exists in some situations
even when the process is officially dead (hence the term ZOMBIE).
Any way you may know all this already.

> > It may be quite handy for the "test server scenario of Ken" you
> > could have something like:
> I don't think so - in most real world cases (OK, in mine), startserver
> will terminate more or less immediately, just after starting yet
> another background process (see "apachectl start" or

But why should only be your way. I would like to have something that 
can accomodate both behaviours.

> OK, I see.  But the fork="yes" doesn't really work either, it is going
> to log output attached to a task that will have fired a "task
> finished" event long ago - something quite a few BuildListeners
> (including our XmlLogger) cannot really deal with.
> There is no problem if we force redirection of the output 8-)

I would like a solution in which redirection is accomodated but also
output to the "ANT Console" (event log) is also supported. We may need
to rething a little and have some pseudo-task doing the daemon execution
of the Thread. Let me take a look and see if I come out with something concrete.

No matter what we do, I think we will need to get a group of people with 
access to different OSs and JDKs to test is we can get some reliable behaviour
as your tests have suggested.

Jose Alberto

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message