mirror of
https://github.com/luxfi/threshold.git
synced 2026-07-27 04:01:59 +00:00
Hanzo AI
b96f926dc0
TestCMPBasicKeygen and TestCMPMinimalKeygen were panicking under -race
with "send on closed channel" because pool.TearDown closed p.commands
while Parallelize was mid-send. The previous code papered over this with
a defer/recover() in Search/Parallelize, but the race detector still
flagged the underlying read-vs-close on the channel field. Replaced the
panic-and-recover hack with a sync.RWMutex (inFlight): senders hold
RLock for the duration of the send loop, TearDown takes the write lock
so it drains every in-flight caller before close(p.commands). Same
pattern applied to Handler's outClosed/close(h.out) sites and safeSend,
which previously check-then-acted with an atomic.Bool — race-prone.
Additionally TestCMPBasicKeygen tripped a saferith.Nat.Cmp race on
shared Pedersen parameters when round4.VerifyMessage and round4.Finalize
ran concurrently in the handler. saferith's Cmp mutates limb storage
even for equal values, so concurrent reads on the same Modulus race.
Added Handler.roundMu serializing VerifyMessage/StoreMessage/
StoreBroadcastMessage/Finalize on the live round.Session — same pattern
in internal/test/round.go for the test harness path used by cmp/sign.
Also tightened pool.Search/Parallelize signal accounting so the caller
receives exactly count signals (one per result write), giving a clean
happens-before edge with every results[i] write — previously the
"for ctr > 0" wait loop could exit before workers had finished writing.
Drive-by: stripped debug fmt.Printf calls from pkg/math/sample/prime.go
and protocols/cmp/keygen/round1.go that had leaked in from a prior
debugging session.
Verification:
go test -race -count=10 -timeout 1200s -run "TestCMPMinimalKeygen|TestCMPBasicKeygen" ./protocols/cmp/
ok 639s
go test -race -count=10 -timeout 600s ./protocols/lss/...
ok (all sub-packages PASS, 200s for ./protocols/lss alone)
go test -race -count=10 -timeout 60s ./pkg/pool/
ok 7s