Conversation
|
|
|
Potentially still to address (in another PR): |
28a5773 to
927f1f0
Compare
927f1f0 to
4c81533
Compare
4c81533 to
e94fddb
Compare
e94fddb to
57555b1
Compare
Signed-off-by: Roman Volosatovs <[email protected]>
- Lazily allocate the slices with capacity optimized for worst case - Refactor the chain of if statements into a switch - Support `repoDigests` and `repoTags` in image summary constructor Signed-off-by: Roman Volosatovs <[email protected]>
- Refactor shared size computation:
- Reduce nesting
- Only mutate image summary struct once, on success
Signed-off-by: Roman Volosatovs <[email protected]>
57555b1 to
d7cda41
Compare
ImageService.ImagesImageService.Images
|
|
||
| // rangeImageLayerChainIDs calls f sequentially for chain ID of each layer image consists of. | ||
| // If f returns false, range stops the iteration. | ||
| func rangeImageLayerChainIDs(img *image.Image, f func(layer.ChainID) bool) { |
There was a problem hiding this comment.
Why don't you just simply return an error in callback? (f func(layer.ChainID) error)
From what I see in the code below we return false if there is an error and true if not, no?
There was a problem hiding this comment.
func rangeImageLayerChainIDs(img *image.Image, f func(layer.ChainID) error) error you can bubble up the error to be more precise
There was a problem hiding this comment.
The only reason is really the consistency with https://pkg.go.dev/sync#Map.Range
But this is definitely an option and probably makes more sense in this case
Maybe naming it forEachImageLayerChainID is better then
There was a problem hiding this comment.
Hmm, after taking a closer look at this, I am not sure if returning an error in the callback is a cleaner solution here.
We have 2 usages here:
- https://github.com/moby/moby/pull/42578/files?w=1#diff-b62ea5c3b3e9f7f294e285690608fbd87d02686b780e1356f4c31652a9542fe7R246-R248 which iterates over all chain IDs always
- https://github.com/moby/moby/pull/42578/files?w=1#diff-b62ea5c3b3e9f7f294e285690608fbd87d02686b780e1356f4c31652a9542fe7R258-R274, which iterates over all chain IDs unless an error is encountered in one of the iterations
If we want to return an error in the callback, then discarding it seems wrong - at least that would not be "idiomatic", so if we want to return an error, I think we would need to propagate it up to the caller.
Now if we refactor it in this way, we get a marginal improvement in usage 2., since now we could wrap the function call into a shortened if as in if err := range...; err != nil and avoid one assignment to err from within the callback. For the usage 1. that would make it more confusing though, in my opinion: the iteration never errors, but now we'd need to either discard the error value returned by the function or check for != nil, which we know would never happen, which is IMO worse than a single assignment to err from within the callback in usage 2.
I.e. I don't think this is worth it:
_ = rangeImageLayerChainIDs(img, func(chid layer.ChainID) error {
layerRefs[chid]++
return nil
})or
if err := rangeImageLayerChainIDs(img, func(chid layer.ChainID) error {
layerRefs[chid]++
return nil
}); err != nil {
return err // or even panic, since this should never happen?
} rangeImageLayerChainIDs(img, func(chid layer.ChainID) error {
layerRefs[chid]++
return nil
})is of course also possible, but that would be confusing, since right below we check for error and here we don't
Do you agree?
|
Doesn't look like there's much need for this, closing. |
A few things extracted from #42550
- What I did
danglingOnlyis true and a tag is foundrangeImageLayerChainIDsfor greater clarity and reducing code duplication- How to verify it
Run
docker imagesanddocker system df