4 ms·

> What GP seems to expect is that sync.Pool() would always return a zeroed structure, just as Golang allocation does. One could define a new "Pool[T]" type (ex

> What GP seems to expect is that sync.Pool() would always return a zeroed structure, just as Golang allocation does. One could define a new "Pool[T]" type (extending sync.Pool) to get these guarantees: type Pool[T any] sync.Pool // typed def func (p *Pool[T]) Get() T { // typed Get pp := (*sync.Pool)(p) return pp.Get().(T) } func (p *Pool[T]) Put(v T) { // typed Put pp := (*sync.Pool)(p) pp.Put(v) } intpool := Pool[int]{ // alias New New: func() any { var zz int; return zz }, } boolpool := Pool[bool]{ // alias New New: func() any { var zz bool; return zz }, } https://go.dev/play/p/-WG7E-CVXHR https://go.dev/play/p/-WG7E-CVXHR

deleted 2y ago
[deleted]
9rx 2y ago
> One could define a new "Pool[T]" type (extending sync.Pool) to get these guarantees: So long as that one is not you? You completely forgot to address the expectation: type Foo struct{ V int } pool := Pool[*Foo]{ // Your Pool type. New: func() any { return new(Foo) }, } a := pool.Get() a.V = 10 pool.Put(a) b := pool.Get() fmt.Println(b.V) // Prints: 10; 0 was expected.
- ignoramous 2y ago
  > You completely forgot to address the expectation > fmt.Println(b.V) // Prints: 10; 0 was expected. Sorry, I don't get what else one expects when pooling pointers to a type? In fact, pooling *[]uint8 or *[]byte is common place; Pool.Put() or Pool.Get() then must zero its contents.
  - 9rx 2y ago
    > I don't get what else one expects when pooling pointers to a type? As seen in your previous comment, the expectation is that the zero value will always be returned: "What GP seems to expect is that sync.Pool() would always return a zeroed structure, just as Golang allocation does." To which you offered a guarantee. > Pool.Put() or Pool.Get() then must zero its contents. Right. That is the solution (as was also echoed in the top comment in this thread) if one needs that expectation to hold. But you completely forgot to do it, which questions what your code was for? It behaves exactly the same as sync.Pool itself... And, unfortunately, doesn't even get the generic constraints right, as demonstrated with the int and bool examples.
    - ignoramous 2y ago
      > And, unfortunately, doesn't even get the generic constraints right, as demonstrated with the int and bool examples. If those constraints don't hold (like you say) it should manifest as runtime panic, no? > What GP seems to expect is that sync.Pool() would always return a zeroed structure Ah, well. You gots to be careful when Pooling addresses. > But you completely forgot to do it, which questions what your code was for? OK. If anyone expects zero values for pointers, then the New func should return nil (but this is almost always useless), or if one expects values to be zeroed-out, then Pool.Get/Put must zero it out. Thanks for the code review.
      - 9rx 2y ago
        > If those constraints don't hold (like you say) it should manifest as runtime panic, no? No. Your int and bool pools run just fine – I can't imagine you would have posted the code if it panicked – but are not correct. > I did not forget? Then your guarantee is bunk: "One could define a new "Pool[T]" type (extending sync.Pool) to get these guarantees:" Why are you making claims you won't stand behind?
        ignoramous 2y ago
        It was a blueprint. Embedding and typedefs are ways to implement these guarantees. And of course, writing a generic pool library is not what I was after. > but are not correct. I don't follow what you're saying. You asserted, "And, unfortunately, doesn't even get the generic constraints right, as demonstrated with the int and bool examples." What does it even mean? I guess, this bikeshed has been so thoroughly built that the discussion points aren't even getting through.
        deleted 2y ago
        [deleted]
        9rx 2y ago
        > What does it even mean? Values are copied in Go. Your code will function, but it won't work. You've left it up to the user of the pool to not screw things up. Which is okay to some degree, but sync.Pool already does that alone, so what is your code for?

deleted 2y ago

[deleted]

9rx 2y ago

> One could define a new "Pool[T]" type (extending sync.Pool) to get these guarantees: So long as that one is not you? You completely forgot to address the expectation: type Foo struct{ V int } pool := Pool[*Foo]{ // Your Pool type. New: func() any { return new(Foo) }, } a := pool.Get() a.V = 10 pool.Put(a) b := pool.Get() fmt.Println(b.V) // Prints: 10; 0 was expected.

ignoramous 2y ago
> You completely forgot to address the expectation > fmt.Println(b.V) // Prints: 10; 0 was expected. Sorry, I don't get what else one expects when pooling pointers to a type? In fact, pooling *[]uint8 or *[]byte is common place; Pool.Put() or Pool.Get() then must zero its contents.
- 9rx 2y ago
  > I don't get what else one expects when pooling pointers to a type? As seen in your previous comment, the expectation is that the zero value will always be returned: "What GP seems to expect is that sync.Pool() would always return a zeroed structure, just as Golang allocation does." To which you offered a guarantee. > Pool.Put() or Pool.Get() then must zero its contents. Right. That is the solution (as was also echoed in the top comment in this thread) if one needs that expectation to hold. But you completely forgot to do it, which questions what your code was for? It behaves exactly the same as sync.Pool itself... And, unfortunately, doesn't even get the generic constraints right, as demonstrated with the int and bool examples.
  - ignoramous 2y ago
    > And, unfortunately, doesn't even get the generic constraints right, as demonstrated with the int and bool examples. If those constraints don't hold (like you say) it should manifest as runtime panic, no? > What GP seems to expect is that sync.Pool() would always return a zeroed structure Ah, well. You gots to be careful when Pooling addresses. > But you completely forgot to do it, which questions what your code was for? OK. If anyone expects zero values for pointers, then the New func should return nil (but this is almost always useless), or if one expects values to be zeroed-out, then Pool.Get/Put must zero it out. Thanks for the code review.
    - 9rx 2y ago
      > If those constraints don't hold (like you say) it should manifest as runtime panic, no? No. Your int and bool pools run just fine – I can't imagine you would have posted the code if it panicked – but are not correct. > I did not forget? Then your guarantee is bunk: "One could define a new "Pool[T]" type (extending sync.Pool) to get these guarantees:" Why are you making claims you won't stand behind?
      - ignoramous 2y ago
        It was a blueprint. Embedding and typedefs are ways to implement these guarantees. And of course, writing a generic pool library is not what I was after. > but are not correct. I don't follow what you're saying. You asserted, "And, unfortunately, doesn't even get the generic constraints right, as demonstrated with the int and bool examples." What does it even mean? I guess, this bikeshed has been so thoroughly built that the discussion points aren't even getting through.
        deleted 2y ago
        [deleted]
        9rx 2y ago
        > What does it even mean? Values are copied in Go. Your code will function, but it won't work. You've left it up to the user of the pool to not screw things up. Which is okay to some degree, but sync.Pool already does that alone, so what is your code for?