misc/ios: serialize iOS execution

The iOS exec wrapper use complicated machinery to run a iOS binary
on a device.
Running several binaries concurrently doesn't work (reliably), which
can break tests running concurrently. For my setup, the
runtime:cpu124 and sync_cpu tests can't run reliably without one of them
crashing.

Add a file lock to the exec wrapper to serialize execution.

Fixes #14318 (for me)

Change-Id: I023610e014b327f8d66f1d2fd2e54dd0e56f2be0
Reviewed-on: https://go-review.googlesource.com/21074
Reviewed-by: David Crawshaw <crawshaw@golang.org>
This commit is contained in:
Elias Naur 2016-03-24 16:03:07 +01:00
parent fc4358951a
commit f045ca8d45
1 changed files with 15 additions and 0 deletions

View File

@ -34,6 +34,7 @@ import (
"runtime"
"strings"
"sync"
"syscall"
"time"
)
@ -76,6 +77,20 @@ func main() {
log.Fatal(err)
}
// This wrapper uses complicated machinery to run iOS binaries. It
// works, but only when running one binary at a time.
// Use a file lock to make sure only one wrapper is running at a time.
//
// The lock file is never deleted, to avoid concurrent locks on distinct
// files with the same path.
lockName := filepath.Join(os.TempDir(), "go_darwin_arm_exec.lock")
lock, err := os.OpenFile(lockName, os.O_CREATE|os.O_RDONLY, 0666)
if err != nil {
log.Fatal(err)
}
if err := syscall.Flock(int(lock.Fd()), syscall.LOCK_EX); err != nil {
log.Fatal(err)
}
// Approximately 1 in a 100 binaries fail to start. If it happens,
// try again. These failures happen for several reasons beyond
// our control, but all of them are safe to retry as they happen