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.
Klaus
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
