fix memleak in safe.Pool #6140
fix memleak in safe.Pool #6140
Conversation
mpl
changed the title
There was a problem hiding this comment.
In fact, I think that the routineCtx slice (or map) is not needed anymore because it was only used for Start mechanism and this mechanism is not used anymore.
I think we should be able to remove all the routines (without Ctx) too, by migrating every old behaviour calls, but this will be done in a future PR.
@mpl I kept the bot/no-merge label for your review, you can merge it when you think it's OK for you.
LGTM |
ldez
added
contributor/waiting-for-corrections
and removed
bot/need-human-merge
contributor/waiting-for-corrections
labels
safe.Pool is not a pool in the usual sense as it is not bounded and it keeps on appending new goroutines, instead of reusing a limited number of goroutines. Moreover, even when a goroutine is done, there's still a small footprint of it, as there is a reference to it that was appended in a slice, and that never gets removed. For this reason, it should not be used in places where potentially lots of go routines are generated, such as in the mirroring service, where there's one go routine per incoming request. Fixes traefik#6125
What does this PR do?
safe.Pool is not a pool in the usual sense as it is not bounded and
it keeps on appending new goroutines, instead of reusing a limited
number of goroutines. Moreover, even when a goroutine is done, there's
still a small footprint of it, as there is a reference to it that was
appended in a slice, and that never gets removed.
This PR fixes the pool by using maps instead of slices, and by making sure the entry in the map corresponding to a goroutine is removed from the map when the goroutine terminates.
Motivation
Fixes #6125
More
[ ] Added/updated tests[ ] Added/updated documentationAdditional Notes
Co-authored-by: Julien Salleyron julien.salleyron@gmail.com