Date: Mon, 6 Oct 2014 09:25:16 -0400
From: Austin Clements <aclements@csail.mit.edu>
To: David Bremner <david@tethera.net>
Subject: Re: [PATCH 02/11] lib: Refactor _notmuch_database_link_message
Message-ID: <20141006132516.GF7970@csail.mit.edu>
References: <1412345958-8278-1-git-send-email-aclements@csail.mit.edu>
	<1412345958-8278-3-git-send-email-aclements@csail.mit.edu>
	<87k34fot7d.fsf@maritornes.cs.unb.ca>
	<20141005232008.GB7970@csail.mit.edu>
	<871tqlpwcx.fsf@maritornes.cs.unb.ca>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <871tqlpwcx.fsf@maritornes.cs.unb.ca>
User-Agent: Mutt/1.5.23 (2014-03-12)
Cc: notmuch@notmuchmail.org
Precedence: list

Quoth David Bremner on Oct 06 at  8:04 am:
> Austin Clements <aclements@csail.mit.edu> writes:
> 
> > Quoth David Bremner on Oct 05 at  9:45 am:
> >> Austin Clements <aclements@csail.mit.edu> writes:
> >> > +    void *local = talloc_new (NULL);
> >> 
> >> What's the advantage of using a local talloc context here? Is this just
> >> an optimization?
> >
> > There are a few allocations that wind up going in to this local
> > context because of the call to _consume_metadata_thread_id, so it's
> > more convenient to free this one context on return from
> > _notmuch_database_link_message than to worry about tracking these
> > various allocations.
> 
> OK, but wouldn't the lazy solution be to use message as a talloc
> context?

That would be the lazy solution, but it would also leak a bunch of
allocations that don't need to live past the end of
_notmuch_database_link_message.