15/513fbadf98166b6e54f14b9138eef56d0c7d93

   1 Return-Path: <cworth@cworth.org>\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 1565F4196F3\r
   6         for <notmuch@notmuchmail.org>; Sat, 24 Apr 2010 07:38:05 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -2.89\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5\r
  12         tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, T_MIME_NO_TEXT=0.01]\r
  13         autolearn=ham\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id XHpgRQ3DDRbr; Sat, 24 Apr 2010 07:38:04 -0700 (PDT)\r
  17 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  18         by olra.theworths.org (Postfix) with ESMTP id EF750431FC1;\r
  19         Sat, 24 Apr 2010 07:38:03 -0700 (PDT)\r
  20 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  21         id A1273568DEC; Sat, 24 Apr 2010 07:38:03 -0700 (PDT)\r
  22 From: Carl Worth <cworth@cworth.org>\r
  23 To: Sebastian Spaeth <Sebastian@SSpaeth.de>,\r
  24         Notmuch development list <notmuch@notmuchmail.org>\r
  25 Subject: Re: Unhandled Xapian exception\r
  26 In-Reply-To: <87aasul8h7.fsf@SSpaeth.de>\r
  27 References: <87aasul8h7.fsf@SSpaeth.de>\r
  28 User-Agent: Notmuch/0.2-174-g6ddc2e0 (http://notmuchmail.org) Emacs/23.1.1\r
  29         (i486-pc-linux-gnu)\r
  30 Date: Sat, 24 Apr 2010 07:38:03 -0700\r
  31 Message-ID: <87bpd8or04.fsf@yoom.home.cworth.org>\r
  32 MIME-Version: 1.0\r
  33 Content-Type: multipart/signed; boundary="=-=-=";\r
  34         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  35 X-BeenThere: notmuch@notmuchmail.org\r
  36 X-Mailman-Version: 2.1.13\r
  37 Precedence: list\r
  38 List-Id: "Use and development of the notmuch mail system."\r
  39         <notmuch.notmuchmail.org>\r
  40 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  41         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  42 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  43 List-Post: <mailto:notmuch@notmuchmail.org>\r
  44 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  45 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  46         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  47 X-List-Received-Date: Sat, 24 Apr 2010 14:38:05 -0000\r
  48 \r
  49 --=-=-=\r
  50 \r
  51 On Fri, 23 Apr 2010 13:21:56 +0200, "Sebastian Spaeth" <Sebastian@SSpaeth.de> wrote:\r
  52 > I propose to try..catch this code block and rather than returning VOID\r
  53 > it could return NOTMUCH_STATUS_SUCCESS or NOTMUCH_XAPIAN_EXCEPTION.\r
  54 > Not sure how "notmuch_database_find_message" would notify the caller of\r
  55 > such an exception situation though. The only possible failure value is\r
  56 > NULL (which also means did not find such a message).\r
  57 \r
  58 We haven't been doing fine-grained exception handling in the library so\r
  59 far. Mostly because the assumption was that there was nothing we could\r
  60 do---when I first wrote the code I assumed that Xapian exceptions would\r
  61 be entirely exceptional.\r
  62 \r
  63 So I just fixed the top-level entry point here to handle this exception\r
  64 in our standard way, (print the message, then return NULL or\r
  65 NOTMUCH_STATUS_XAPIAN_EXCEPTION).\r
  66 \r
  67 While at this, I audited all notmuch_database calls to ensure they\r
  68 follow this scheme. (I have not yet audited all libnotmuch entry\r
  69 points.)\r
  70 \r
  71 Meanwhile, we've recently discovered that there is a Xapian exception\r
  72 that is not all that exceptional. Since database readers don't lock the\r
  73 database, it's not hard to have one or more readers accessing the\r
  74 database when a writer comes along and modifies the database. This\r
  75 triggers the readers to subsequently fail with a DatabaseModified\r
  76 exception.\r
  77 \r
  78 I don't know how conceivable it would be to fix that at the Xapian\r
  79 level. It might be quite nice if opening a database in read-only mode\r
  80 gave access to a snapshot of the database as it exists at that time. But\r
  81 that might be a feature that's entirely unreasonable to implement.\r
  82 \r
  83 Otherwise, we might want to start supporting more clever handling of the\r
  84 exception. For example, the high-level application might want to retry\r
  85 an operation if it fails due to a DatabaseModified exception. To support\r
  86 this, you would want your python bindings to have a layer that would\r
  87 catch the C++ exception and re-throw a python exception.\r
  88 \r
  89 And to support that, we would need a different scheme in the\r
  90 library. Basically to just document that all calls might throw an\r
  91 exception and then not catch and print anything. That would at least be\r
  92 much simpler in the library. Then the top-level "notmuch" application\r
  93 could just have a C++ wrapper for main() that would catch and print the\r
  94 exception message.\r
  95 \r
  96 What do you think?\r
  97 \r
  98 -Carl\r
  99 \r
 100 --=-=-=\r
 101 Content-Type: application/pgp-signature\r
 102 \r
 103 -----BEGIN PGP SIGNATURE-----\r
 104 Version: GnuPG v1.4.10 (GNU/Linux)\r
 105 \r
 106 iD8DBQFL0wJL6JDdNq8qSWgRAtTCAJ932UJpRa5Xo8A18sNeEGUtK06o3wCgodD7\r
 107 elDDcN+LgfeCGGO6+bl3LYA=\r
 108 =wE/h\r
 109 -----END PGP SIGNATURE-----\r
 110 --=-=-=--\r