On 09/27/2018 07:44 PM, Francis wrote:
> I believe the pool does not track the objects that it returns from a
> call to `Get()`. I would be surprised if it did track these objects.
> There is no real need for it to track these objects.
Exactly, that was my point. Else there would be no reason to call Put()
> I think now your proposal makes a lot more sense to me. If I understand
> correctly you had understood that the sync.Pool would track all the
> instances of objects it had created, via Get(), and so they wouldn't be
> GCed, This would be (to me) a very surprising implementation of sync.Pool.
No. My understanding of sync.Pool is that only the objects Put() back
into it would be subject to GC. (I could of course, just read the source)
The objects handed out by Get() and still in the hand of the program
would be the responsibility of the application.
My intention was then to handle that responsibility by temporarily
storing these pointers as uintptr and by using them as a value in a map,
be able to exploit the map-of-non-pointers optimization to avoid GC
scans of the map.
... and of course remember to Put() back any map entries delete()'ed
from the map and any entries left before the reference to the map it
self is forgotten and the map is left to be garbage collected.
/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.
