On 7 Apr 2007, at 14:41, Fergal Daly wrote:
If you're testing web applications, you can fire off forks or threads. So instead of serially waiting for each network operation to complete, let them run in parallel. This could help to get wallclock-time closer to cpu-time. You could put each set of tests in it's own script (might be easy, might not), fire off each script outputting to it's own file and then run the tap consumer over each file in turn and join all the results up. Or you could just give each thread/process it's own test prefix and let them off to do their own thing.
I'd rather just give each thread its own stream and TAP::Parser and mix everything together further upstream in that case. If you want to capture all the TAP have each parser spool to a different file and then concatenate them all.
This doesn't seem to be motivation of the original poster was asking about, however joining multiple streams becomes easy, you just prefix each line with "$n." where $n is the number of the file.
I think you just don't join TAP streams in that way. How do you handle YAMLish diag blocks that follow a numbered test? How do you handle plan lines?
You'd have to prepend a source identifier to each line - and doing that is really just a standard trick (see logfiles) that doesn't really feel like it should be part of TAP.
Using BEGIN/END works for the non-real time however it seems like it would be better to use a solution that works equally well in either situation,
Trying to solve the realtime problem by turning each line of TAP into a packet with a source idntifier and then streaming them over a single pipe is bonkers. We don't need to mux/demux streams for network transmission. TCP/IP does that pretty well.
-- Andy Armstrong, hexten.net
