Max Kirillov <[email protected]> writes:
> On Sat, Nov 24, 2018 at 04:47:19PM +0900, Junio C Hamano wrote:
>> I do agree that forcing the parent to wait, like you described in
>> the comment, would be far more preferrable,
>
> It looks like it can be done as simple as:
>
> --- a/http-backend.c
> +++ b/http-backend.c
> @@ -486,6 +486,8 @@ static void run_service(const char **argv, int
> buffer_input)
> if (buffer_input || gzipped_request || req_len >= 0)
> cld.in = -1;
> cld.git_cmd = 1;
> + cld.clean_on_exit = 1;
> + cld.wait_after_clean = 1;
> if (start_command(&cld))
> exit(1);
>
> at least according to strate it does what it should.
Sounds sane.
I am offhand not sure what the right value of wait_after_clean for
this codepath be, though. 46df6906 ("execv_dashed_external: wait
for child on signal death", 2017-01-06) made this non-default but
turned it on for dashed externals (especially to help the case where
they spawn a pager), as the parent has nothing other than to wait
for the child to exit in that codepath. Does the same reasoning
apply here, too?
This is a meta point, but I wonder if there is an easy way to "grep"
for uses of run-command interface that do *not* set clean_on_exit.
The pager that can outlive us long after we exit, kept alive while
the user views our output, is an example cited by afe19ff7
("run-command: optionally kill children on exit", 2012-01-07), and
while I am wondering if the default should hae been to kill the
children instead, such a "grep" would have been very useful to know
what codepaths would be affected if we flipped the default.
