ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <>
Subject Re: [PATCH] Asynchronous execution of processes
Date Tue, 13 Nov 2001 12:18:53 GMT
looks as if the mail server has eaten the text/plain part of my mail,
I'll ping Pier.  Here it is:

On Fri, 9 Nov 2001, Jose Alberto Fernandez <>

> 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.

> 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
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.

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.

> 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

> From: "Stefan Bodewig" <>
>> Why does detach imply fork for <java> using your implementation?
>> You could as well wrap a daemon thread around invoking the classes
>> main as well.
> The problem is with the management of IO using DemuxOutputStream

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-)


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

View raw message