Johannes Schindelin [off-list ref] writes:
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?
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"?
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
Hi,
On Wed, 21 Jan 2009, Jeff King wrote:
On Wed, Jan 21, 2009 at 04:42:22PM -0800, Junio C Hamano wrote:
quoted
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.
I _suspect_ that the svn tests already use different ports (or can work
with the same httpd), as I have subversion installed and run with -j50
regularly.
Ciao,
Dscho
On Thu, Jan 22, 2009 at 06:02:51AM +0100, Johannes Schindelin wrote:
I _suspect_ that the svn tests already use different ports (or can work
with the same httpd), as I have subversion installed and run with -j50
regularly.
I think you're just not running them; it looks like they bail if
SVN_HTTPD_PORT isn't set by the user.
-Peff