> On 29 Sep 2016, at 18:57, Junio C Hamano <gits...@pobox.com> wrote: > > Torsten Bögershausen <tbo...@web.de> writes: > >>> 1) Git exits >>> 2) The filter process receives EOF and prints "STOP" to the log >>> 3) t0021 checks the content of the log >>> >>> Sometimes 3 happened before 2 which makes the test fail. >>> (Example: https://travis-ci.org/git/git/jobs/162660563 ) >>> >>> I added a this to wait until the filter process terminates: >>> >>> +wait_for_filter_termination () { >>> + while ps | grep -v grep | grep -F "/t0021/rot13-filter.pl" >/dev/null >>> 2>&1 >>> + do >>> + echo "Waiting for /t0021/rot13-filter.pl to finish..." >>> + sleep 1 >>> + done >>> +} >>> >>> Does this look OK to you? >> Do we need the ps at all ? >> How about this: >> >> +wait_for_filter_termination () { >> + while ! grep "STOP" LOGFILENAME >/dev/null >> + do >> + echo "Waiting for /t0021/rot13-filter.pl to finish..." >> + sleep 1 >> + done >> +} > > Running "ps" and grepping for a command is not suitable for script > to reliably tell things, so it is out of question. Compared to > that, your version looks slightly better, but what if the machinery > that being tested, i.e. the part that drives the filter process, is > buggy or becomes buggy and causes the filter process that writes > "STOP" to die before it actually writes that string? > > I have a feeling that the machinery being tested needs to be fixed > so that the sequence is always be: > > 0) Git spawns the filter process, as it needs some contents to > be filtered. > > 1) Git did everything it needed to do and decides that is time > to go. > > 2) Filter process receives EOF and prints "STOP" to the log. > > 3) Git waits until the filter process finishes. > > 4) t0021, after Git finishes, checks the log.
A pragmatic approach: I could drop the "STOP" message that the filter writes to the log on exit and everything would work as is. We could argue that this is OK because Git doesn't care anyways if the filter process has stopped or not. Would that be OK for everyone? - Lars
