Sorry I've been so quiet on this recently. I've been a little under the weather.
On Fri, 9 Sep 2011 13:53:28 -0400, Austin Clements <amdragon at MIT.EDU> wrote: > Ah, the *Python* objects don't care, but the underlying C objects do. > Suppose the Query were finalized first. Python calls Query.__del__, > which calls notmuch_query_destroy, which releases the underlying > talloc references to the C notmuch_messages_t objects, causing talloc > to free the notmuch_messages_t. Messages._msgs now points to freed > memory, so when Python then finalizes the Messages object, > Messages.__del__ will pass this dangling pointer to > notmuch_messages_destroy, which will crash. Exactly. This is exactly what I suspect is happening in my case. > > Hence my suggestion that, rather than trying to emulate C-style memory > management in bindings, bindings should create an additional talloc > reference to the underlying objects and rather than calling > notmuch_*_destroy during finalization, they should simply unlink this > additional reference. Currently talloc's reference counting interface is hidden behind _destroy. While this might be a fairly intrusive change, perhaps notmuch wants to juse expose a pair of reference counting *_ref/unref functions instead of the *_destroy. Most users would simply need to change existing *_destroy()s to _unref()s. Furthermore, this would allow bindings authors to easily ensure non-broken GC behavior. Does this sound completely insane, somewhat insane, or reasonable? Cheers, - Ben