Re: [PATCH] t6500: don't run detached auto gc at the end of the test script
- From
SZEDER Gábor <szeder.dev@gmail.com>
- Date
- Apr 12, 2017, 22:03 UTC
- Message-ID
- <CAM0VKjkuoCotm8FB5qdTQsC0SaJiwBA9dXmdLJdSs8NwLdY8fQ@mail.gmail.com>
- In-Reply-To
- <20170412005011.46tr4mgsxk7chgfz@sigill.intra.peff.net>
On Wed, Apr 12, 2017 at 2:50 AM, Jeff King <peff@peff.net> wrote:
Show 25 quoted lines
> On Wed, Apr 12, 2017 at 02:27:05AM +0200, SZEDER Gábor wrote:
>
>> >> I wonder if you could make it a general test-lib function, like:
>> >>
>> >> run_and_wait () {
>> >> # we read stdout from the child only for the side effect
>> >> # of waiting until all child sub-processes exit, closing their
>> >> # fd 9.
>> >> does_not_matter=$("$@" 9>&1)
>> >
>> >
>> > I'm afraid this won't work on Windows when the invoked command is git. FD
>> > inheritance between MSYS (bash) and non-MSYS programs (git) is only
>> > implemented for FDs 0,1,2. That's a deficiency of MSYS, and I don't think
>> > that was improved in MSYS2.
>>
>> Oh, that's a pity, I was almost ready with v2...
>>
>> Unfortunately, this makes the general helper function unworkable, of
>> course. Though in this particular case it wouldn't matter, because on
>> Windows daemonize() is basically a noop and 'git gc --auto' remains in
>> the foreground anyway.
>
> That makes it tempting to use in this scenario as a one-off with a
> comment.Ok, I'll send it out in a minute, and Junio can then take his pick.
Show 8 quoted lines
>> I think we should stick with my initial patch, then. > > I'm not entirely opposed, but my understanding was that it didn't > actually fix the race, it just made it a bit bigger. Which is sort of > unsatisfying. > > I couldn't get the original to show a failure, though, even under heavy > load. So maybe widening the race is enough.
Just to be clear: it's only an occasionally appearing error message. There is no failure in the sense of test failure, because 'rm -rf $trash' erroring out during housekeeping does not fail the test suite.