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 Fri, 09 Nov 2001 01:54:45 GMT
From: "Stefan Bodewig" <>

> > The changes do not rely on any OS specifics (all Java) and you can
> > still use the timeout option to stop the forked process (as long as
> > ANT's VM is still running).
> I'm not sure whether this satisfies all use cases people have for
> detach, leaving the currently running VM completely would probably be
> preferred by most people.  Maybe we should use your version for all
> the OSes we don't have an OS dependent version for?

There are two issues here, first what to do with IO if not redirected; and
second what does each OS does when the VM that spawn the process ends.
In the case of Win2k the process will stay running if there is no IO to stdout/err.

As someone suggested we could do something about redirecting IO to a file
which it cannot be done today, but taha is only if the user specifies usage of a file.

> The Unix case would be more or less trivial as long as detach="true"
> implies running via a shell script.  A platform dependent solution
> would make the use of a timeout feature impossible, but I don't think
> a combination of detach (which is spawn and forget about it in my
> book) and timeout is something people will need anyway.

It may be quite handy for the "test server scenario of Ken" you could have
something like:
    <target ....>
        <exec timeout="1h" executable="startserver" detach="true"..../>
        <run-tests ....>
        <exec executable="stopserver" />

If the test get stuck, then the server will be terminated after the timeout which should
make any further stuff to finish and fail. Granted, this does not cover all cases
but you can see it may be useful. 

> 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 (which is what the
code does), as far as I understand the code it relies on knowing which thread is running 
which task at any particular time. But the code would be running on a different
thread not under the control of Project, so this looks like a problem.

Notice that the code when fork is true, does not rely on  DemuxOutputStream to redirect the
to the correct task.

Jose Alberto

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

View raw message