Hi, On Wed, 21 Jan 2009, Jeff King wrote: > On Wed, Jan 21, 2009 at 02:26:56AM +0100, Johannes Schindelin wrote: > > > Well, in this case, you will find that the "bug" is _at most_ some > > binaries not being found. > > [...] > > (Actually, with my new patch, the may be replaced, but _only_ if > > necessary, and the same thing would apply as I said earlier: the binary > > would not be found, or a binary from the PATH would be run without > > valgrind; but the next runs will not have the problem.) > > You can run a random binary from the PATH. No. You seem to assume that a test script can run all kinds of Git commands while another, is replacing the symlinks in $GIT_VALGRIND/bin/ at the same time. Fact is: every test script will check $GIT_VALGRIND/bin/ for up-to-dateness first. Before running any Git command. During that time, races are possible, but non-fatal, because they all try to do the same thing. Except, of course, if you replace a script by a builtin _while your test is running the up-to-date check of $GIT_VALGRIND/bin/_! But I would have no word of consolation for you in that case. So, can we agree that every test script tries to keep $GIT_VALGRIND/bin/ up-to-date before the first Git command is called? Now, you might assume that it is possible that one test-script symlinked the Git command while another removed it. But the script that removed the symlink will recreate it right away. Granted, during that time, the other script could have gone off to call a Git command in that very brief time span, but keep in mind: it does not take a long time from rm to ln -s, _and_ the other script would have to go on to call a Git command _right through that time_. And you know which command that might be? Exactly. git init. Which takes a long, long, long time, and where I really could not care less if it is called from the PATH or not. Note: this would be only possible if both scripts checked the same name at the very same time, coming to the very same result that the name needs symlinking. Unlikely. Note, too: such a replacing/creating could only take place the very first time you run valgrind, or when a script was replaced by a builtin. IOW very, very rarely to begin with. Now the big question: is this highly, highly unlikely issue relevant? And I say: no. Because even in that highly, highly, highly unlikely event, all that will happen is that a git init (which is tested later, anyway) is not valgrinded. Besides, if that race would happen _and_ you would see any issues, you'd run the test again, without parallelization, because you would not be able to discern what messages belong together from the output of "make -j50 test" anyway. And the whole issue goes away, because that call will again try to make GIT_VALGRIND/bin up-to-date, and there will be no chance for a race this time. Phew. A lot of time, a lot of braincycles, and a lot of keystrokes wasted on that subject, don't you think? Ciao, Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
