FAQ
I've built a simple resource pool with the intention of using it to pool
connections to an as of yet undecided database store for various hobby
projects. It provided a good first exercise, but I need to be a bit more
secure with my grasp of go before I start building out too much the wrong
way ;)

I've got a few questions before I go on to the next component - here's the
pool: https://github.com/jkassemi/pool.go

1. The pool constructor, NewPool, returns a new Pool struct that's been
initialized with the correct channel. I can't find it now, but I recalled
reading somewhere in the documentation that you should be able to use make
to initialize a new struct and just expect that struct to be usable at that
point. Is there a better way of writing this without using the constructor
function? Should interfaces to this system create their own channel?
2. On line 26 of pool_test.go, there's a type assertion on the return,
since the channel returns an untyped interface pointer - I looked into
using reflect to determine the type of interface sent to the channel,
storing the type in a separate struct, etc, but don't have a good method of
returning the same type to the calling code. Is there a graceful way to
handle this and return the same type from the interface?
3. My first iteration of the pool system didn't use buffered channels,
and was a bit larger in scope. When I introduced the channels to this
system the library shrunk dramatically. In a typical go project would it be
better to implement the pool within the library requiring it, or is this a
pattern worth extracting?
4. Github/Bitbucket/Google Code - is there a service that's clearly
beginning to dominate that I should be using or at least becoming more
familiar with?


If you would be willing to put in the time to tear this library down line
by line to recommend better practices in the future (documentation,
testing, benchmarks , style and examples), I'd really appreciate it, and
will happily return the favor.

Thanks!

--

Search Discussions

  • Gary b at Dec 27, 2012 at 2:35 am
    Responses to your questions:

    1. The constructor function is the best approach. Name the function New to
    avoid stuttering.

    2. There is not a graceful way to avoid the type assertion.

    3. A couple of things work against sharing this code. A type specific pool
    is more convenient to use (no type assertions) and easy to implement using
    buffered channels as you noted. A pool for some databases can benefit from
    specific knowledge about the database.

    4. Go works with all of the version control services in your list. Github
    is the most popular service for Go projects (see http://godoc.org/-/index),
    but I don't think that's a reason to use Github.

    More comments:

    - Many database clients for Go provide pooling.

    - Pick a new projet name without the ".go" suffix. See the last paragraph
    at http://golang.org/cmd/go/#hdr-Description_of_package_lists for info on
    how go tool handles paths ending with ".go".

    - In the Get method, use http://godoc.org/time#After instead of sleeping in
    a goroutine.

    - The Get and Register methods are not thread-safe.

    --
  • Sugu Sougoumarane at Dec 28, 2012 at 12:48 am
    Vitess uses connection pools for databases. Take a look at:
    http://code.google.com/p/vitess/source/browse/go/pools/roundrobin.go

    It creates connections (resources) as needed, and is capable of dynamic
    resizing. It uses a channel, but only as a FIFO buffer. For
    synchronization, it actually uses sync.Cond because we ran into race
    conditions and deadlocks (thanks to Dmitry's inputs) that we couldn't
    overcome with channels.

    Sample use here:
    http://code.google.com/p/vitess/source/browse/go/vt/tabletserver/conn_pool.go

    --
  • Kevin Gillette at Dec 28, 2012 at 12:56 am
    make is used only for the mutable reference types: slice, map, and chan.
    To initialize a struct, use one of the forms:

    T{a, b, c}
    T{A: A, C: C}
    &T{a, b, c}
    &T{A: A, C: C}

    The last two will return initialized *T values, while the first two will
    just return T values.
    On Wednesday, December 26, 2012 1:13:10 PM UTC-7, James Kassemi wrote:

    I've built a simple resource pool with the intention of using it to pool
    connections to an as of yet undecided database store for various hobby
    projects. It provided a good first exercise, but I need to be a bit more
    secure with my grasp of go before I start building out too much the wrong
    way ;)

    I've got a few questions before I go on to the next component - here's the
    pool: https://github.com/jkassemi/pool.go

    1. The pool constructor, NewPool, returns a new Pool struct that's
    been initialized with the correct channel. I can't find it now, but I
    recalled reading somewhere in the documentation that you should be able to
    use make to initialize a new struct and just expect that struct to be
    usable at that point. Is there a better way of writing this without using
    the constructor function? Should interfaces to this system create their own
    channel?
    2. On line 26 of pool_test.go, there's a type assertion on the return,
    since the channel returns an untyped interface pointer - I looked into
    using reflect to determine the type of interface sent to the channel,
    storing the type in a separate struct, etc, but don't have a good method of
    returning the same type to the calling code. Is there a graceful way to
    handle this and return the same type from the interface?
    3. My first iteration of the pool system didn't use buffered channels,
    and was a bit larger in scope. When I introduced the channels to this
    system the library shrunk dramatically. In a typical go project would it be
    better to implement the pool within the library requiring it, or is this a
    pattern worth extracting?
    4. Github/Bitbucket/Google Code - is there a service that's clearly
    beginning to dominate that I should be using or at least becoming more
    familiar with?


    If you would be willing to put in the time to tear this library down line
    by line to recommend better practices in the future (documentation,
    testing, benchmarks , style and examples), I'd really appreciate it, and
    will happily return the favor.

    Thanks!
    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedDec 26, '12 at 11:47p
activeDec 28, '12 at 12:56a
posts4
users4
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase