MIME-Version: 1.0
In-Reply-To:
 <CADv3eyxcu=2ZJ7GH3WULKMqe6FdmzhPtU6K9MLcCQ4m0cWmM7A@mail.gmail.com>
References: <1335185032-13075-1-git-send-email-felipe.contreras@gmail.com>
	<CADv3eywAvyMuh3vWLwyuf0Ui_kskwp9875pGxCR1GTm7deN9Pg@mail.gmail.com>
	<CAMP44s3SyU4WVV0_McHWseNL=jmMnAXO2EdZK4Xk-wrCHPVD8A@mail.gmail.com>
	<CADv3eywb0tguYowTAK5Ag9YZ48zFZA0QJVNEj_cZcCpr-76Bbg@mail.gmail.com>
	<CAMP44s0=m+PmVBdVytHaYujpaZu=2WH+1F_VoMzpfXH+SS_ZmQ@mail.gmail.com>
	<CADv3eyxcu=2ZJ7GH3WULKMqe6FdmzhPtU6K9MLcCQ4m0cWmM7A@mail.gmail.com>
Date: Tue, 24 Apr 2012 03:45:46 +0300
Message-ID:
 <CAMP44s2qmPWZk=1N8L1aOnDb7b81kthNB-Gj798wdwBdtbBjFQ@mail.gmail.com>
Subject: Re: [PATCH] ruby: make sure the database is closed
From: Felipe Contreras <felipe.contreras@gmail.com>
To: Ali Polatel <alip@exherbo.org>
Content-Type: text/plain; charset=UTF-8
Cc: notmuch@notmuchmail.org
Precedence: list

On Tue, Apr 24, 2012 at 2:46 AM, Ali Polatel <alip@exherbo.org> wrote:
> 2012/4/24 Felipe Contreras <felipe.contreras@gmail.com>:

>> Personally I don't see why an object, like say a query would remain
>> working correctly after the database is gone, either by calling
>> .close() directly, or just loosing the pointer to the original object.
>> I don't think users would expect that, or, even if they somehow found
>> it useful, that most likely would be very seldom, and hardly worth
>> worrying about it.
>
> Working correctly is not expected but wouldn't it be more appropriate
> to throw an exception rather than dumping core or printing on standard error?

Sure, if that was possible.

> I wonder whether we can make both work somehow.
> Maybe by using talloc explicitly and keeping reference pointers?
> I don't know whether it's worth bothering.

Maybe, I don't see how, that's just not how C works. Maybe talloc does
have some way to figure out if a pointer has been freed, but I doubt
that, and I can't find it by grepping through the API.

Another option would be hook into talloc's destructor so we know when
an object is freed and taint it, but then we would be overriding
notmuch's destructor, and there's no way around that (unless we tap
into talloc's internal structures). A way to workaround that would be
to modify notmuch's API so that we can specify a destructor for
notmuch objects, but that would be tedious, and I doubt a lof people
beside us would benefit from that.

In the meantime, it doesn't hurt to apply this patch.

-- 
Felipe Contreras