Le 19/10/2012 06:55, Ethan Glasser-Camp a ?crit :
> Adrien Bustany 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
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
Adrien Bustany 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 notmuch_messages_t
> being GC'ed before a notmuch_message_t belonging to
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
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 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 owner reference, combined
>>> with
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
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
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 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 notmuch_messages_t
being GC'ed before a notmuch_message_t belonging to it), we add for each
wraper
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
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 notmuch_messages_t
being GC'ed before a notmuch_message_t belonging to it), we add for each
wraper
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
14 matches
Mail list logo
