However, I'd also like to add a finalizer to the pool object, using
runtime.SetFinalizer, to close any connections when the pool is
garbage collected, in case the user forgets to explicitly close it.
But if I have a background timeout goroutine, it seems to me that it
must hold a reference to the pool object in order to close the pool's
connections, but that reference means the finalizer will never be
called on the pool... So it looks like I can have either a finalizer
or a timeout handler, but not both. How to resolve this seeming
Catch-22? Or do I need to wait for weakrefs? ;)
John
type Conn struct {
*conn
}
give out *Conn to the clients and put the finalizer there.
keep conn in your timeout cache.
Is the rule that a reference to an embedded struct doesn't prevent the
container struct from being garbage collected (and therefore
finalized)?
FWIW I'm using this on a connection pool I've implemented for my
PostgreSQL client wrapper. Source is at
https://github.com/jbarham/pgsql.go/blob/master/pool.go. Initially I
tried using a channel but in the end decided it was simpler just to a
use a list w/ sync.Cond. Is there some Go concurrency idiom I'm
missing and should be using instead?
John
The rule is that if there is no references to an object it gets
garbage collected( and finalized)
A reference to an embedded struct would prevent it's container from
being collected.
But in this case it's just an embedded pointer.
- jessta
--
=====================
http://jessta.id.au