CC @dvyukov

This may be hard to fix; this isn't a race in the traditional sense. (It's only a race if the object is then pulled out of the pool again before the next GC.) I don't know if the race detector has enough options to handle this.

@pascaldekloe do you have any real bug? If it's in open-source code, please point to it.

@quentinmit race detector has acquire, release annotations and ignores. It should be enough.

The problem with straightforward enabling of Pool under race detector is that it will introduce lots of parasitic synchronization (esp the Mutex) that can hide lots of unrelated races.

We could annotate Pool to synchronize on the objects cached (i.e. if goroutine A takes object X put by goroutine B, then A synchronizes only with B). But values are not necessary pointers.
We could also enable cache probablistically -- randomly decide to Put or to drop.

The uncommited code was ment for an opensource project. I've chosen to use a buffered channel as a pool instead.

Here's a playground example: https://play.golang.org/p/vwn35eBL8-

CL https://golang.org/cl/31589 mentions this issue.