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 notmuch_messages_
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 notmuch_messages_t
being G
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
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 tracki
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 tracki
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 t
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 the fact that
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 orde
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 de
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 orde
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 destroye
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 struc
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 com
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 com
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 struc
16 matches
Mail list logo