5 ms·

I'm excited about sync.Pool: http://tip.golang.org/pkg/sync/#Pool http://tip.golang.org/pkg/sync/#Pool There are a lot of cases where people write their own v

I'm excited about sync.Pool: http://tip.golang.org/pkg/sync/#Pool http://tip.golang.org/pkg/sync/#Pool There are a lot of cases where people write their own version of this (myself included, but also the connections in database/sql for example). It will be great to have an implementation in the standard library. This technique has been very, very useful in StatHat's production code as we have grown.

mediocregopher 12y ago
Reading the documentation, it seems that sync.Pool will automatically shrink the pool size when it's not being used? If so, unless in the future it provides some way to specify a cleanup function for those values, using it for connections and the like would result in hanging connections (I think, not 100% sure).
- kisielk 12y ago
  It only removes values that have been put back in to the pool. The assumption is that anything you've put back in to the pool has already been cleaned up to a state where it's ready to be used again when it's taken out.
  - Someone 12y ago
    That's exactly the complaint. You don't use a connection pool to get rid of allocs and frees, but to get rid of lengthy calls that initialise the connection. Because of that, you don't want to close your connection before returning it to the pool. So, the pool will have to close those connections whenever it disposes of an object in the pool. I don't know enough go to interpret what 'might be deallocated' means in this part of http://tip.golang.org/pkg/sync/#Pool http://tip.golang.org/pkg/sync/#Pool: "Any item stored in the Pool may be removed automatically at any time without notification. If the Pool holds the only reference when this happens, the item might be deallocated." Is there some interface{} similar to C++ destructors, or is that a reference to the fact that the garbage collector need not deallocate unreachable objects?
    - mediocregopher 12y ago
      There's not a destructor method like there is in C++. I'm not sure why they defined Pool to only interact with interface{}, it seems like it would have been much easier to define an interface which looks like: type PoolObject interface { Destroy() } And have it interact with that. The NewPool func would look like: func NewPool(func() PoolObject) Pool EDIT: Changed my code a bit
  - noselasd 12y ago
    Which would mean if you use it as a connection pool, you'd be at the mercy of the garbage collector as to when the connection gets closed if it's pruned from the pool.
frou_dh 12y ago
I'm looking forward to it too. I think it'll be a good way to have one-per-type free-lists inside my toy language implementation. At the moment, garbage is created like crazy in there for all the short-lived immutable values.

mediocregopher 12y ago

Reading the documentation, it seems that sync.Pool will automatically shrink the pool size when it's not being used? If so, unless in the future it provides some way to specify a cleanup function for those values, using it for connections and the like would result in hanging connections (I think, not 100% sure).

kisielk 12y ago
It only removes values that have been put back in to the pool. The assumption is that anything you've put back in to the pool has already been cleaned up to a state where it's ready to be used again when it's taken out.
- Someone 12y ago
  That's exactly the complaint. You don't use a connection pool to get rid of allocs and frees, but to get rid of lengthy calls that initialise the connection. Because of that, you don't want to close your connection before returning it to the pool. So, the pool will have to close those connections whenever it disposes of an object in the pool. I don't know enough go to interpret what 'might be deallocated' means in this part of http://tip.golang.org/pkg/sync/#Pool http://tip.golang.org/pkg/sync/#Pool: "Any item stored in the Pool may be removed automatically at any time without notification. If the Pool holds the only reference when this happens, the item might be deallocated." Is there some interface{} similar to C++ destructors, or is that a reference to the fact that the garbage collector need not deallocate unreachable objects?
  - mediocregopher 12y ago
    There's not a destructor method like there is in C++. I'm not sure why they defined Pool to only interact with interface{}, it seems like it would have been much easier to define an interface which looks like: type PoolObject interface { Destroy() } And have it interact with that. The NewPool func would look like: func NewPool(func() PoolObject) Pool EDIT: Changed my code a bit
- noselasd 12y ago
  Which would mean if you use it as a connection pool, you'd be at the mercy of the garbage collector as to when the connection gets closed if it's pruned from the pool.

frou_dh 12y ago

I'm looking forward to it too. I think it'll be a good way to have one-per-type free-lists inside my toy language implementation. At the moment, garbage is created like crazy in there for all the short-lived immutable values.