Documentation
¶
Overview ¶
Package syncutil re-exports Mutex and RWMutex so the rest of the codebase can declare lock fields without caring whether a build wants the plain runtime primitives (this file, the default) or the instrumented ones from mutex_deadlock.go (`go test -tags deadlock`, `go run -tags deadlock`).
Every mutex-typed field in internal/ should use syncutil.Mutex / syncutil.RWMutex instead of sync.Mutex / sync.RWMutex so a `-tags deadlock` build/test run gets deadlock detection everywhere, not just in the one package that happened to need it. See mutex_deadlock.go for why: this exists because internal/agent/loop.go shipped a self-deadlock (appendToolResults held cfg.HistoryLock and called annotateToolCall, which locked the same non-reentrant mutex again) that hung every multi-tool-call turn for as long as the session ran, with no test catching it — every test that exercised that path used a nil lock, the one configuration where re-locking is a silent no-op instead of a hang.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type PollingRWMutex ¶
PollingRWMutex always uses sync.RWMutex, including deadlock-tagged builds.
It is reserved for context-aware acquisition loops that repeatedly call TryLock or TryRLock. go-deadlock v0.3.9 removes an existing holder from its bookkeeping after a failed try-lock from another goroutine, so instrumenting such polling would make later recursive-lock and lock-order reports unsound. Keep ordinary locks on Mutex/RWMutex so the detector covers them.
Source Files