> I may just be missing something, but doesn't "struct child_process" > already have e.g. "no_stderr", "no_stdout" etc. that we can use? > I.e. isn't this thing equivalent to running: > > your-command >/dev/null 2>/dev/null > > Which is what the non-parallel API already supports. > > Now, IIRC if you just set that in the "get_next_task" callback it won't > work in the parallel API, or you'll block waiting for I/O that'll never > come or whatever. > > But that'll be because the parallel interface currently only suppors a > subset of the full "child_process" combination of options, and maybe it > doesn't grok this. > > But if that's the case we should just extend the API to support > "no_stdout", "no_stderr" etc., no? > > I.e. hypothetically the parallel one could support 100% of the "struct > child_process" combination of options, we just haven't bothered yet. > > But I don't see why the parallel API should grow options that we already > have in "struct child_process", instead we should set them there, and it > should gradually learn to deal with them. > > I think it's also fine to have some basic sanity checks there, e.g. I > could see how for something like this we don't want to support piping > only some children to /dev/null but not others, and that it should be > all or nothing (maybe it makes state management when we loop over them > easier). > > Or again, maybe I'm missing something... Shouldn't the options that are set in "child_process" be abstracted away from "parallel_processes"? Setting "no_stdout", "no_stderr", etc. in a "child_process" shouldn't imply that we still pass the stdout and stderr to "parallel_processes" and then we send the output to "/dev/null". That being said, I can understand the aversion to adding an option like this that doesn't also add support for stdout and stderr. I can remove this patch and instead reset the buffer inside of pipe_output and task_finished in a later patch
