ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Klaus Malorny <>
Subject Re: extended parallelism
Date Wed, 19 Dec 2007 08:21:35 GMT
Chuck Holzwarth wrote:
> Perhaps the facility that spawns the targets could manage the screen/buffer
> output. This would mean that some facility would have to exist similar to
> named pipes in Unix. This way, console output would be directed from the
> buffer (or pipe) that had first output while other targets would be producing
> output that could be buffered or spooled to disk (high volume of output) for
> later display. A GUI that would be integrated would possibly have access to
> the streams in a windowed type display but the end result should probably
> display the console format even if views of the running thread outputs are
> allowed.

Yes, large output would have to be paged to disk.

Basically, a GUI can easily insert the respective output in the output window 
where the target started, thus keeping the output in one block. A console output 
could do the same _if_ it would support something like "curses" and implement 
something like a "more" or "less" frontend. But likely nobody wants to integrate 
such a rather old-fashioned technology.

Thinking a little bit more about the issue, I was wondering whether it would be 
a good idea to integrate the target-level parallelism (as discussed here) and 
the task-level parallelism (i.e. <parallel> task) into one beast, as such issues 
like output handling and maximum number of threads executed in parallel could 
benefit from it.

> How would antform be handled?

Never heard of it before, but googling for it, such a task would simply have to 
queue up the requests and prompt them to the user one after another.


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

View raw message