Jeff King <peff@xxxxxxxx> writes:
> I don't think you need exact timing information. This is no different
> than running the commands themselves, with stdout and stderr writing to
> a pty that your terminal emulator will then read() from. If the program
> produces intermingled stdout/stderr that clogs up the terminal, that is
> its problem.
>
> The only difference is that we're going to save it and later replay it
> all very quickly. So I think it would be sufficient just to retain the
> original order.
>
>> I will add documentation explaining why the async output case
>> will only deal with one channel. I chose stderr as that's already
>> available and needed in this use case.
>
> I suspect you could just set child->stdout_to_stderr in this case, and
> then you get your ordering for free.
I think we are in agreement; that is exactly what I wanted to say
when I said "I offhand do not think the latter [i.e. the callers
have to dup them together] is unreasonable". Thanks for stating it
more clearly and explicitly.
> To handle multiple channels, I think you could just do a linked list of
> buffers rather than a single strbuf. Like:
>
> struct io_chunk {
> int channel;
> char *buf;
> size_t len;
> struct io_chunk *next;
> };
>
> and just keep appending chunks to the list (and to dump them, just walk
> the list, writing each to the appropriate channel descriptor).
Perhaps, but let's not overdesign things before we have a concrete
example codepath that benefits from such a thing. It is hard to
detect a misdesign without a real usage pattern.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html