Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id D4B1A431E82 for ; Sat, 31 Mar 2012 20:23:29 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCtt3O6dNdY9 for ; Sat, 31 Mar 2012 20:23:29 -0700 (PDT) Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU [18.7.68.34]) by olra.theworths.org (Postfix) with ESMTP id 4BB43431FAF for ; Sat, 31 Mar 2012 20:23:29 -0700 (PDT) X-AuditID: 12074422-b7fd66d0000008f9-27-4f77ca2e907a Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP id AC.0C.02297.E2AC77F4; Sat, 31 Mar 2012 23:23:26 -0400 (EDT) Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id q313NP9U008716; Sat, 31 Mar 2012 23:23:25 -0400 Received: from awakening.csail.mit.edu (awakening.csail.mit.edu [18.26.4.91]) (authenticated bits=0) (User authenticated as amdragon@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.6/8.12.4) with ESMTP id q313NNNk011529 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sat, 31 Mar 2012 23:23:24 -0400 (EDT) Received: from amthrax by awakening.csail.mit.edu with local (Exim 4.77) (envelope-from ) id 1SEBNz-0000cq-Dp; Sat, 31 Mar 2012 23:23:23 -0400 Date: Sat, 31 Mar 2012 23:23:23 -0400 From: Austin Clements To: Justus Winter <4winter@informatik.uni-hamburg.de> Subject: Re: [RFC] Split notmuch_database_close into two functions Message-ID: <20120401032323.GH5949@mit.edu> References: <1332291311-28954-1-git-send-email-4winter@informatik.uni-hamburg.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1332291311-28954-1-git-send-email-4winter@informatik.uni-hamburg.de> User-Agent: Mutt/1.5.21 (2010-09-15) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IRYrdT19U7Ve5vsP6AjMXs1h9MFtdvzmR2 YPKYeP40m8ezVbeYA5iiuGxSUnMyy1KL9O0SuDKu7XrCWjCPreL5vyksDYzdrF2MnBwSAiYS V3ftZYOwxSQu3FsPZHNxCAnsY5Q4+eoJE4SzgVHi2puDUM5JJokVr0+zQDhLGCWmX+4C62cR UJVYu/42I4jNJqAhsW3/cjBbRMBUYsODB+wgNrOAtMS3381MILawgJPEmguTwOK8AtoSHe03 wWwhgUCJnuuP2SDighInZz5hgejVkrjx7yVQLwfYnOX/OEDCnAJBEqtnLQYrERVQkZhychvb BEahWUi6ZyHpnoXQvYCReRWjbEpulW5uYmZOcWqybnFyYl5eapGuqV5uZoleakrpJkZwYLso 7WD8eVDpEKMAB6MSD6/WjHJ/IdbEsuLK3EOMkhxMSqK8044DhfiS8lMqMxKLM+KLSnNSiw8x SnAwK4nwdq8u8RfiTUmsrEotyodJSXOwKInzqmu98xMSSE8sSc1OTS1ILYLJynBwKEnw2pwE GipYlJqeWpGWmVOCkGbi4AQZzgM03BCkhre4IDG3ODMdIn+KUVFKnNcLJCEAksgozYPrhSWe V4ziQK8I85qCVPEAkxZc9yugwUxAg5l5Qa4uLklESEk1MMoKOJrEB5j5H4i+JMf8XCHirpja h3mMFw47XX+zo0fd54nJmVgmkYU/TkT/Pu8vLLVrwgnbncoHF50/eelAvEnnm97Ahc9u9M1q ltJ3snj58U33XrkStptbHl05V3eC82vI59ovl1Tl9Va8sDq3KKBX85SrbuAqs4I/XbpBb+Se GPq3H1vWlK/EUpyRaKjFXFScCAC1keNFFwMAAA== Cc: notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Apr 2012 03:23:30 -0000 Quoth Justus Winter on Mar 21 at 1:55 am: > I propose to split the function notmuch_database_close into > notmuch_database_close and notmuch_database_destroy so that long > running processes like alot can close the database while still using > data obtained from queries to that database. Is this actually safe? My understanding of Xapian::Database::close is that, once you've closed the database, basically anything can throw a Xapian exception. A lot of data is retrieved lazily, both by notmuch and by Xapian, so simply having, say, a notmuch_message_t object isn't enough to guarantee that you'll be able to get data out of it after closing the database. Hence, I don't see how this interface could be used correctly. Maybe you could describe your use case in more detail?