Re: valgrind patches, was Re: What's cooking in git.git (Jan 2009, #04; Mon, 19)

On Wed, Jan 21, 2009 at 04:42:22PM -0800, Junio C Hamano wrote:

quoted

Fact is: every test script will check $GIT_VALGRIND/bin/ for 
up-to-dateness first.  Before running any Git command.

Hmm, is that a good thing in general?  Can't makefile rules be arranged in
such a way that one "valgrind-prep" target runs before all the potentially
parallel executions of actual tests begin?

You have to choose either "everybody does this setup, whether they want
--valgrind or not" which is what my original patch did, or doing it
inside test-lib.sh. Because we don't know we want --valgrind until we
get into the individual scripts.

I suppose one could try parsing GIT_TEST_OPTS in the Makefile, but that
seems a bit hack-ish.

But I like putting it into test-lib.sh; yes, it is a little more CPU
time for each script, but it is negligible compared to running the
actual tests (especially since you only pay when running with
--valgrind, which makes the actual tests very expensive). But it is much
easier to be sure it is _correct_ when you run the test, especially if
you tend to run the test script directly.

Independent from the above, I suspect that some of the existing tests
cannot run in parallel; I haven't really looked at any of them, but a
server-ish tests to open a local port and test interaction with client
obviously need to either use different ports or serialize.  Perhaps we
need a way to mark some tests that cannot be run in parallel even under
"make -j"?

I think the only culprits are http-push and a few SVN tests. The
http-push test starts a server on a specific port, but because it is the
only script which uses that port, it is fine. It looks like a few
different SVN tests start an httpd server (9115, 9118, and 9120), which
could potentially interact badly. I've never had a problem running with
"-j4", but I don't have svn installed, so I always end up skipping those
tests.

It looks like both the http-push and svn tests are set up to take an
arbitrary port as input. Perhaps the simplest thing would be for each of
the svn tests to pick a different port so that they can be run
simultaneously.

-Peff