No offense, sorry for high jacking, I was trying to counter point their usefulness, as a way to limit additional resources being spent to improve GC when using them, since I think their application is error prone in many most? cases.
> On Sep 27, 2018, at 9:30 AM, Peter Mogensen <a...@one.com> wrote: > > > >> On 09/27/2018 04:20 PM, Ian Davis wrote: >> >> https://github.com/golang/go/issues/23199 describes another gotcha when >> using pools: pinning of memory buffers. >> > > Yes... that's a good point for people considering to use sync.Pool. > > For the purpose of this question however, let's assume the decision to > use sync.Pool for the actual objects already has been taken and that > knowing when to call Put() is not an issue. > We can also perfectly assume that the pool managed objects are NOT of > variable size (as in the above link) and do not use growing buffers, > either by bytes.Buffer or by using append() ... which is actually the > case for my current code. > > I hope I'm not rude, when I try to steer this thread back on topic and > avoid that it degenerates to a discussion of whether sync.Pool is hard > to use in general - which was not the intention of my original question > regarding the fix in https://go-review.googlesource.com/c/go/+/3288 > > Well meaning, > Peter > > -- > You received this message because you are subscribed to the Google Groups > "golang-nuts" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to golang-nuts+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
