doc/progs: flaky on OpenBSD

[mdempsky]

These tests are flaking on OpenBSD (both 386 and amd64) a lot:

https://storage.googleapis.com/go-build-log/8c918ef1/openbsd-amd64-gce56_503d834e.log

[mdempsky]

It looks like 5451fff introduced a race condition (@josharian @bradfitz), but I'm not sure why it's only flaking on OpenBSD.

The problem is we're (simplified) concurrently running "go build go1.go; ./go1; rm go1" and "go build slices.go; ./slices; rm slices".

Within go1, there's a call to filepath.Walk(".", walkFn). filepath.Walk reads the list of files in the directory, then proceeds to lstat each of them, and call walkFn. What's happening is "slices" exists when go1 is reading the list of files in the directory, but the other test has removed it before go1 gets around to lstat'ing it. Then walkFn fails, which causes go1 to call log.Fatal, which causes doc/progs/run.go to fail.

Previously this was not a problem because:

1. The tests were synchronous.
2. All of the test programs were built first, then some of them were run, then they were all deleted.

Two options I see:

1. Build the test programs in a separate temporary directory and run them from there, like how "go run" works.
2. Build the programs in parallel, then test them in parallel, then delete them all.

[josharian]

Blech. Thanks for tracking that down. It seems like option 1 would more closely maintain the prior behavior.

[mdempsky]

Do you mean option 2 would be closer to maintain the prior behavior? doc/progs/run used to be roughly:

for i in $all; do
  go build $i.go
done

testit blah1...
testit blah2...

rm -f $all

Either way, I'll look into a fix later, but feel free to steal the issue if you want.

[josharian]

If you're willing to take it, it's all yours.