On 05/18/2012 03:45 PM, Jameson Graef Rollins wrote: > On Fri, May 18 2012, Austin Clements <amdragon@MIT.EDU> wrote: >> It's slightly awkward that it's the caller's responsibility to free >> this lazily constructed object. That should probably be documented. >> We could more carefully reference count it, but I think that would >> actually be worse because the reference count would probably bounce >> through zero frequently. > > I agree that this is awkward. Is there a suggestion on how to do it > better? We only want to initialize it if it's needed, and only > _mime_node_create knows that. And we don't want to free it with > _mime_node_context_free, or something, only to have to reinitialize it > again with the next node or message. Thoughts? You could provide a "destructor" function for notmuch_crypto_t, which whoever is responsible for the struct would need to call when they are ready to dispose of it. The destructor would just destroy any GMIME crypto contexts pointed to by the struct, and reset those pointers to NULL. Since the common workflow is a singleton notmuch_crypto_t that is a subobject of the singleton notmuch_params_t, you could just call that destructor function before the notmuch_params_t falls out of scope. If you want to be fancy/symmetric, you could use the same pattern to create a "destructor" function for notmuch_params_t (it would just invoke the destructor on its crypto member), but this seems like overkill to me, and not in line with the talloc approach of the rest of the codebase. I agree that it's a little awkward, but i think there's something of an impedance mismatch between gmime's object interface and notmuch's use of talloc and friends. --dkg