On Tuesday, March 5, 2013 2:38:32 AM UTC-6, John Nagle wrote:
on the following GC".That's not usually what's meant by a "weak reference".
Weak references are useful in Python, which is mostly
reference-counted. If you have a tree-like data structure
with backlinks, backlinks should be weak references. Then
if you discard part of the tree, it gets released by the
reference count mechanism. But Go is purely GC, so
that's not a win.
The combination of weak references and parallelism introduce
some strange problems. You have to convert a weak reference
to a strong one before using it, and that conversion must be
an atomic operation. Now there's a locking problem associated
with weak references. Messy.
If you want to release excess memory held by some cache,
it's appropriate to keep a last-use number or timestamp
on each item, and periodically run a goroutine to drop old
items.
Hooking program semantics to the GC is generally a mistake.
Calling destructors/finalizers from a GC is extremely messy.
It's done in Microsoft Managed C++. Read this discussions:
http://www.codeproject.com/Articles/7965/Deterministic-Destruction-in-C-CLI
You do not want to take Go there.
On 3/4/2013 11:58 PM, Dmitry Vyukov wrote:
On Tue, Mar 5, 2013 at 9:46 AM, Dustin <dsal...@gmail.com <javascript:>>
wrote:On Tue, Mar 5, 2013 at 9:46 AM, Dustin <dsal...@gmail.com <javascript:>>
On Monday, March 4, 2013 10:56:05 PM UTC-8, Dmitry Vyukov wrote:
I am not sure how one can want something along the lines of "discardon the following GC".
Weak references are useful in Python, which is mostly
reference-counted. If you have a tree-like data structure
with backlinks, backlinks should be weak references. Then
if you discard part of the tree, it gets released by the
reference count mechanism. But Go is purely GC, so
that's not a win.
The combination of weak references and parallelism introduce
some strange problems. You have to convert a weak reference
to a strong one before using it, and that conversion must be
an atomic operation. Now there's a locking problem associated
with weak references. Messy.
If you want to release excess memory held by some cache,
it's appropriate to keep a last-use number or timestamp
on each item, and periodically run a goroutine to drop old
items.
Hooking program semantics to the GC is generally a mistake.
Calling destructors/finalizers from a GC is extremely messy.
It's done in Microsoft Managed C++. Read this discussions:
http://www.codeproject.com/Articles/7965/Deterministic-Destruction-in-C-CLI
You do not want to take Go there.
John Nagle
But I agree, I use some time based cache's with a dedicated cleanupgoroutine.
To cleanup they just forget an object and eventually the gc grabs it.
Weak pointers have always scared me.
--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
