1 Return-Path: <amdragon@mit.edu>
\r
2 X-Original-To: notmuch@notmuchmail.org
\r
3 Delivered-To: notmuch@notmuchmail.org
\r
4 Received: from localhost (localhost [127.0.0.1])
\r
5 by olra.theworths.org (Postfix) with ESMTP id BCA20431FAF
\r
6 for <notmuch@notmuchmail.org>; Mon, 23 Apr 2012 18:15:33 -0700 (PDT)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5
\r
12 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled
\r
13 Received: from olra.theworths.org ([127.0.0.1])
\r
14 by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
\r
15 with ESMTP id XOJhte3pNoke for <notmuch@notmuchmail.org>;
\r
16 Mon, 23 Apr 2012 18:15:33 -0700 (PDT)
\r
17 Received: from dmz-mailsec-scanner-4.mit.edu (DMZ-MAILSEC-SCANNER-4.MIT.EDU
\r
19 by olra.theworths.org (Postfix) with ESMTP id 051C6431FAE
\r
20 for <notmuch@notmuchmail.org>; Mon, 23 Apr 2012 18:15:32 -0700 (PDT)
\r
21 X-AuditID: 1209190f-b7f8a6d000000914-6a-4f95feb45ea6
\r
22 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39])
\r
23 by dmz-mailsec-scanner-4.mit.edu (Symantec Messaging Gateway) with SMTP
\r
24 id 5A.63.02324.4BEF59F4; Mon, 23 Apr 2012 21:15:32 -0400 (EDT)
\r
25 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])
\r
26 by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id q3O1FUfv000505;
\r
27 Mon, 23 Apr 2012 21:15:31 -0400
\r
28 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91])
\r
29 (authenticated bits=0)
\r
30 (User authenticated as amdragon@ATHENA.MIT.EDU)
\r
31 by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q3O1FTmT014132
\r
32 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);
\r
33 Mon, 23 Apr 2012 21:15:30 -0400 (EDT)
\r
34 Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77)
\r
35 (envelope-from <amdragon@mit.edu>)
\r
36 id 1SMULo-00046f-OU; Mon, 23 Apr 2012 21:15:28 -0400
\r
37 Date: Mon, 23 Apr 2012 21:15:28 -0400
\r
38 From: Austin Clements <amdragon@MIT.EDU>
\r
39 To: Felipe Contreras <felipe.contreras@gmail.com>
\r
40 Subject: Re: [PATCH] ruby: make sure the database is closed
\r
41 Message-ID: <20120424011528.GA12459@mit.edu>
\r
42 References: <1335185032-13075-1-git-send-email-felipe.contreras@gmail.com>
\r
43 <CADv3eywAvyMuh3vWLwyuf0Ui_kskwp9875pGxCR1GTm7deN9Pg@mail.gmail.com>
\r
44 <CAMP44s3SyU4WVV0_McHWseNL=jmMnAXO2EdZK4Xk-wrCHPVD8A@mail.gmail.com>
\r
45 <CADv3eywb0tguYowTAK5Ag9YZ48zFZA0QJVNEj_cZcCpr-76Bbg@mail.gmail.com>
\r
46 <CAMP44s0=m+PmVBdVytHaYujpaZu=2WH+1F_VoMzpfXH+SS_ZmQ@mail.gmail.com>
\r
47 <CADv3eyxcu=2ZJ7GH3WULKMqe6FdmzhPtU6K9MLcCQ4m0cWmM7A@mail.gmail.com>
\r
48 <CAMP44s2qmPWZk=1N8L1aOnDb7b81kthNB-Gj798wdwBdtbBjFQ@mail.gmail.com>
\r
50 Content-Type: text/plain; charset=us-ascii
\r
51 Content-Disposition: inline
\r
53 <CAMP44s2qmPWZk=1N8L1aOnDb7b81kthNB-Gj798wdwBdtbBjFQ@mail.gmail.com>
\r
54 User-Agent: Mutt/1.5.21 (2010-09-15)
\r
55 X-Brightmail-Tracker:
\r
56 H4sIAAAAAAAAA+NgFprFKsWRmVeSWpSXmKPExsUixG6nrrvl31R/g97zHBarvt1ltDj4OM/i
\r
57 +s2ZzA7MHhufNrF77Jx1l93j2apbzAHMUVw2Kak5mWWpRfp2CVwZ0w+1sxVcEaiYvXoJawPj
\r
58 Wt4uRk4OCQETiRXrTjNB2GISF+6tZ+ti5OIQEtjHKPGveRELhLOBUWLPytlQmZNMEhv3/ITK
\r
59 LGGU2Hx9PitIP4uAqsTWY72MIDabgIbEtv3LwWwRAUOJve1TWUBsZgFriXuHtoLZwkD2mSN7
\r
60 wGxeAR2JqVdms0IM/cIs8XvzKmaIhKDEyZlPoJq1JG78ewl0LAeQLS2x/B8HSJhTIFCi8cgi
\r
61 sB9EBVQkppzcxjaBUWgWku5ZSLpnIXQvYGRexSibklulm5uYmVOcmqxbnJyYl5dapGuil5tZ
\r
62 opeaUrqJERTsnJL8Oxi/HVQ6xCjAwajEw5uVPtVfiDWxrLgy9xCjJAeTkijvyt9AIb6k/JTK
\r
63 jMTijPii0pzU4kOMEhzMSiK8iROAcrwpiZVVqUX5MClpDhYlcV41rXd+QgLpiSWp2ampBalF
\r
64 MFkZDg4lCV4eYFQLCRalpqdWpGXmlCCkmTg4QYbzAA1f8hdkeHFBYm5xZjpE/hSjLse1L0ev
\r
65 MAqx5OXnpUqJ864GKRIAKcoozYObA0tSrxjFgd4S5t0NUsUDTHBwk14BLWECWpIQMwlkSUki
\r
66 QkqqgZG3xWHqvjdGjzalfdm24raRWPz5uPA2u9WNaxvLpxzMmHTUevnDkoSE2tshXW+Svj66
\r
67 67d52zuVVMOY2fcsFm3b9I/txwYpuVdbtx+cvCEn+DGPt+dGEzPGfRyb9LmOcZvwbZY9v3Pn
\r
68 NW7P17EPq+KV314sOp16zPIgjyrXpGezz0g056VG1SgosRRnJBpqMRcVJwIA2G+3ry0DAAA=
\r
69 Cc: Ali Polatel <alip@exherbo.org>, notmuch@notmuchmail.org
\r
70 X-BeenThere: notmuch@notmuchmail.org
\r
71 X-Mailman-Version: 2.1.13
\r
73 List-Id: "Use and development of the notmuch mail system."
\r
74 <notmuch.notmuchmail.org>
\r
75 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
76 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
77 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
78 List-Post: <mailto:notmuch@notmuchmail.org>
\r
79 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
80 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
81 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
82 X-List-Received-Date: Tue, 24 Apr 2012 01:15:33 -0000
\r
84 Quoth Felipe Contreras on Apr 24 at 3:45 am:
\r
85 > On Tue, Apr 24, 2012 at 2:46 AM, Ali Polatel <alip@exherbo.org> wrote:
\r
86 > > 2012/4/24 Felipe Contreras <felipe.contreras@gmail.com>:
\r
88 > >> Personally I don't see why an object, like say a query would remain
\r
89 > >> working correctly after the database is gone, either by calling
\r
90 > >> .close() directly, or just loosing the pointer to the original object.
\r
91 > >> I don't think users would expect that, or, even if they somehow found
\r
92 > >> it useful, that most likely would be very seldom, and hardly worth
\r
93 > >> worrying about it.
\r
95 > > Working correctly is not expected but wouldn't it be more appropriate
\r
96 > > to throw an exception rather than dumping core or printing on standard error?
\r
98 > Sure, if that was possible.
\r
100 > > I wonder whether we can make both work somehow.
\r
101 > > Maybe by using talloc explicitly and keeping reference pointers?
\r
102 > > I don't know whether it's worth bothering.
\r
104 > Maybe, I don't see how, that's just not how C works. Maybe talloc does
\r
105 > have some way to figure out if a pointer has been freed, but I doubt
\r
106 > that, and I can't find it by grepping through the API.
\r
108 > Another option would be hook into talloc's destructor so we know when
\r
109 > an object is freed and taint it, but then we would be overriding
\r
110 > notmuch's destructor, and there's no way around that (unless we tap
\r
111 > into talloc's internal structures). A way to workaround that would be
\r
112 > to modify notmuch's API so that we can specify a destructor for
\r
113 > notmuch objects, but that would be tedious, and I doubt a lof people
\r
114 > beside us would benefit from that.
\r
116 I believe (though I might be wrong) that bindings could simply
\r
117 maintain their own talloc references to C objects returned by
\r
118 libnotmuch to prevent them from being freed until the wrapper object
\r
119 is garbage collected. This would require modifying all of the
\r
120 library's _destroy functions to use talloc_find_parent_bytype and
\r
121 talloc_unlink instead of simply calling talloc_free, but I don't think
\r
122 this change would be particularly invasive and it certainly wouldn't
\r
123 affect the library interface.
\r