On 2013/12/19 16:20:58, rsc wrote:
not lgtm
sync.Pool is not for short-lived free lists, especially ones that are
already managed inside of another data structure. The free list inside the
Decoder only lives as long as the Decoder does. There is no need for what
sync.Pool contributes.
sync.Pool solves a real problem for global free lists. Since this case is
not a global free list, sync.Pool has very little to contribute here.
not lgtm
sync.Pool is not for short-lived free lists, especially ones that are
already managed inside of another data structure. The free list inside the
Decoder only lives as long as the Decoder does. There is no need for what
sync.Pool contributes.
sync.Pool solves a real problem for global free lists. Since this case is
not a global free list, sync.Pool has very little to contribute here.
Are we talking about current non-final non-scalable Pool implementation?
Or the final, scalable one? Or both?
The plan here, as I see it:
1. Make the Pool scalable
2. Replace the local pools in gob with a global one
https://codereview.appspot.com/44050044/
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
