This makes a Pool unsuited for managing objects which require explicit deallocation; e.g., objects with an associated open file or active goroutine.

Why put such objects in the pool in the first place?

sync.Pool is not a cache, that was an explicit design decision.

Why put such objects in the pool in the first place?

Why put any object in a pool?

sync.Pool is not a cache, that was an explicit design decision.

Someone should update the documentation, then: "Pool's purpose is to cache allocated but unused items for later reuse..."

In CL/41860043, Russ states the following:

I answered your question about eviction signals by pointing out that this
is not a cache. It is a free list. "Eviction" is for caches. A cache holds
a set of non-interchangeable objects, each of which represents a different
computation or effort that might be repeated if an eviction is necessary.
In a cache, it is important that the eviction policy predict the future
needs as well as possible so that the impact of an eviction is put off for
as long as possible. A free list holds a set of interchangeable,
indistinguishable pieces of memory, each of which is just sitting waiting
to be used for bypassing a memory allocation and holds no other value.
"Eviction" is not something that makes sense for free lists.

@neild yup, that is really bad wording. I remember at the time the discussion went something along the lines of “it’s called sync.Pool, because it doesn’t have cache semantics, it can happily throw away anything you put in it”

I don't want to quibble on the semantics of "cache" vs. "free list", but the question of whether objects require release is orthogonal to whether they are interchangeable.

I believe Russ's comment in CL/41860043 is regarding eviction policy in the sense of deciding when and whether to remove objects from the pool. This feature request isn't about controlling when items are removed from the pool, but to have a way to clean them up when they are.

Practically speaking, the implementation of sync.Pool performs cleanup at a stop-the-world moment with the additional restriction that the cleanup logic cannot allocate. I'm no expert in GC, but it seems that any implementation of Pool.Release would have the same restrictions where 1) the user's function should not allocate, and 2) the function is fast to avoid hurting the GC pause time. I would not want any API that ever exposes these details to the user.

If sync.Pool cleans up at GC then why not just use runtime.Setfinalizer?
https://golang.org/pkg/runtime/#SetFinalizer

@neild I fully agree with @AlexRouSg, that's exactly what finalizers are for, so much so that they are used in the standard library exactly for the use cases you're describing (closing file descriptors associated with an object being GCed):

Finalizers don't work for an object with an associated goroutine.

If a goroutine holds a pointer to an object that is also held by a sync.Pool, you are probably using sync.Pool incorrectly.

@chowey You've got it backwards. I suspect @neild is talking about a sync.Pool that holds an object that points to something that the goroutine also points to (e.g., a set of channels for communicating with that goroutine).

I'm sure you can make finalizers work for this, in the worst case by putting in the pool a wrapper that has the finalizer attached but is not referenced by any other goroutine. Please do that.

I regret having one kind of finalizer already. I would regret having two kinds at least four times as much. (You can decide whether my regret is quadratic or exponential in the number of finalizer kinds.)

/cc @aclements @RLH

Also:

Someone should update the documentation, then: "Pool's purpose is to cache allocated but unused items for later reuse..."

I can see why this wording would seem appropriate — in this case, what's being cached is unused items, not used items. But I suppose, given this thread, a question would be does this merit rewording? I'm not sure how much more obscure the term "free list" is.