From: Ben Gamari <bgamari.foss@gmail.com>
To: notmuch <notmuch@notmuchmail.org>, Carl Worth <cworth@cworth.org>
Subject: Re: Memory management practices
In-Reply-To: <87liucyn7i.fsf@gmail.com>
References: <8739h1pbaq.fsf@gmail.com> <87pqjprzu2.fsf@gmail.com>
	<20110829183010.GA2605@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f>
	<87liucyn7i.fsf@gmail.com>
User-Agent: Notmuch/0.7-37-g5c3c7f6 (http://notmuchmail.org) Emacs/23.2.1
	(x86_64-pc-linux-gnu)
Date: Wed, 07 Sep 2011 16:36:08 -0400
Message-ID: <87aaag3xaf.fsf@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Bertram Felgenhauer <bertram.felgenhauer@googlemail.com>,
	Bart Massey <bart@cs.pdx.edu>
Precedence: list

On Mon, 29 Aug 2011 16:30:57 -0400, Ben Gamari <bgamari.foss@gmail.com> wrote:
> [SNIP]
> 
> In general, it seems to me that memory management in notmuch bindings is
> a little bit harder than it needs to me due to the decision not to
> talloc_ref parent objects when a new child object is created. This means
> that a bindings author needs to recreate the ownership tree in their
> binding, a task which is fairly easily done (except in the case of
> Haskell due to the weak GC finalization guarantees) but seems quite
> unnecessary. Is there a reason this decision was made? Would a patch be
> accepted adding talloc_ref'ing parents in those functions creating
> children and talloc_frees in *_destroys?
> 
Any opinions concerning whether this is an acceptable idea? I wouldn't
mind putting together a patch-set, but I'd rather not waste my time if
the set would ultimately be rejected due to some technical objection I
have yet to think of.

Cheers,

- Ben