The original implementation wrote to different locations in a shared slice.
While this is theoretically okay, we end up thrashing the cpu cache since
multiple slice members may be on the same cache line. So, even though each
thread has its own memory location, there may be contention over the cache
line. This changes the code to aggregate to a slice in a single goroutine.
In reality, this change likely won't have any performance impact. The theory
proposed above hasn't really even been tested. Either way, we can consider it
and possibly go forward.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
To avoid compounded round trips leading to slow retrieval of manifests with a
large number of signatures, the fetch of signatures has been parallelized. This
simply spawns a goroutine for each path, coordinated with a sync.WaitGroup.
Signed-off-by: Stephen J Day <stephen.day@docker.com>
Add a SignatureService and expose it via Signatures() on Repository so
external integrations wrapping the registry can access signatures.
Move signature related code from revisionstore.go to signaturestore.go.
Signed-off-by: Andy Goldstein <agoldste@redhat.com>
