Le 19/10/2012 06:55, Ethan Glasser-Camp a écrit :
Adrien Bustany adr...@bustany.org writes:
This makes notmuch appropriately free the underlying notmuch C objects
when garbage collecting their Go wrappers. To make sure we don't break
the underlying links between objects (for example, a
Quoth Adrien Bustany on Jul 24 at 1:03 am:
Le 20/07/2012 06:23, Austin Clements a écrit :
Quoth Adrien Bustany on Jul 19 at 9:25 pm:
Le 18/07/2012 23:40, Austin Clements a écrit :
This is subtle enough that I think it deserves a comment in the source
code explaining that tracking the talloc
Le 18/07/2012 23:40, Austin Clements a écrit :
This is subtle enough that I think it deserves a comment in the source
code explaining that tracking the talloc owner reference, combined
with the fact that Go finalizers are run in dependency order, ensures
that the C objects will always be
Quoth Adrien Bustany on Jul 19 at 9:25 pm:
Le 18/07/2012 23:40, Austin Clements a écrit :
This is subtle enough that I think it deserves a comment in the source
code explaining that tracking the talloc owner reference, combined
with the fact that Go finalizers are run in dependency order,
This is subtle enough that I think it deserves a comment in the source
code explaining that tracking the talloc owner reference, combined
with the fact that Go finalizers are run in dependency order, ensures
that the C objects will always be destroyed from the talloc leaves up.
Just one inline
