ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steve Loughran <>
Subject Re: How to pipe output to input?
Date Thu, 23 Jun 2005 15:25:07 GMT
Matt Benson wrote:
> --- Steve Loughran <> wrote:
>>Peter Nabbefeld wrote:
>>>I've asked this question on the users list, but it
>>seems nobody knows 
>>>Is it possible to create two java processes (with
>>fork="true") and pipe 
>>>the output of one process into the other?
>>Not yet :)
>>Ant1.6.2 added the notion of the ioredirector to
>>exec and java, but no 
>>direct coupling of apps. You'd have to write your
>>own filter to route 
>>the stuff...and ant equivalent of Unix named pipes
> Yep.  To let my own proverbial (dead) cat out of the
> bag,

Schoedinger says the cat is only dead or alive when you open the bag

> this was one of my original goals when I exposed
> the redirector functionality.  After committing the
> current functionality, I had added the additional
> concept of an (input|output|error)ref attribute: 
> inputref would specify a reference to an inputstream
> from which input should be read; (output|error)ref
> would specify a reference to an inputstream from which
> another process could read, created using a
> PipedOutputStream->PipedInputStream (actually an
> oata.util.LeadPipeInputStream) set.  Concurrency
> issues were solved by a ProxyInputStream class; while
> locking at the Redirector class level (no new stream
> references added), the Project would be probed for the
> named InputStream.  If none were found, a
> ProxyInputStream would be created that would continue
> to search for the (literally) "named pipe".  This all
> worked like a charm...
> ...on Unix (Solaris, I like to think it probably would
> have worked on other Unix systems).  I could not for
> all the world convince the stupid Windows JREs not to
> deadlock on any but the simplest uses of this.  I have
> since lost that bit of code, but could re-create if
> any Threading gurus want to take a stab at it.
> -Matt

Interesting design. I would have done a <namedpipe id="" /> datatype 
that did the synchronisation; producers and consumers would sync by 
choice of pipename. But like you say, the problem becomes process 
co-ordination; handling failures and propagating them gracefully, or 
just how to keep processes around until their consumer/producer was 
there. This is the stuff we normally delegate to the OS, or, for 
distrubution, to some message queue. Though named pipes work across 
clusters, at least on the apollo and hpux cluster systems.


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

View raw message