FAQ

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.

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.

Search Discussions

  • Russ Cox at Dec 20, 2013 at 5:07 pm

    On Fri, Dec 20, 2013 at 1:24 AM, wrote:
    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.

    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
    I don't see any need to replace the local free lists with a global one.
    That's exactly the overuse I want to avoid, exactly the overuse that will
    cause us to take sync.Pool back out of the library.

    As I explained above, the most significant feature of sync.Pool is that it
    lets the runtime influence when memory is released. That is not necessary
    in this case, as I explained above. The memory will be released when the
    Decoder is released.

    Russ

    --

    ---
    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedDec 20, '13 at 6:24a
activeDec 20, '13 at 5:07p
posts2
users2
websitegolang.org

2 users in discussion

Russ Cox: 1 post Dvyukov: 1 post

People

Translate

site design / logo © 2022 Grokbase