01/2aadc5e0690c27f3bc0bc103bad9d181d9e50b

   1 Return-Path: <thomas@schwinge.name>\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 CD38B431FB6\r
   6         for <notmuch@notmuchmail.org>; Thu, 27 Jan 2011 10:20:08 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0 tagged_above=-999 required=5\r
  12         tests=[RCVD_IN_DNSWL_NONE=-0.0001] 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 Y9Y3EzVy0zjl for <notmuch@notmuchmail.org>;\r
  16         Thu, 27 Jan 2011 10:20:08 -0800 (PST)\r
  17 Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de\r
  18         [80.67.31.32])\r
  19         by olra.theworths.org (Postfix) with ESMTP id DAE3A431FB5\r
  20         for <notmuch@notmuchmail.org>; Thu, 27 Jan 2011 10:20:07 -0800 (PST)\r
  21 Received: from [87.180.40.233] (helo=stokes.schwinge.homeip.net)\r
  22         by smtprelay04.ispgateway.de with esmtpa (Exim 4.68)\r
  23         (envelope-from <thomas@schwinge.name>) id 1PiWRy-00068u-Hq\r
  24         for notmuch@notmuchmail.org; Thu, 27 Jan 2011 19:20:06 +0100\r
  25 Received: (qmail 8335 invoked from network); 27 Jan 2011 18:20:04 -0000\r
  26 Received: from kepler.schwinge.homeip.net (192.168.111.7)\r
  27         by stokes.schwinge.homeip.net with QMQP; 27 Jan 2011 18:20:04 -0000\r
  28 Received: (nullmailer pid 12761 invoked by uid 1000);\r
  29         Thu, 27 Jan 2011 18:20:04 -0000\r
  30 From: Thomas Schwinge <thomas@schwinge.name>\r
  31 To: notmuch@notmuchmail.org\r
  32 Subject: notmuch's idea of concurrency / failing an invocation\r
  33 User-Agent: Notmuch/0.5-33-g665f77b (http://notmuchmail.org) Emacs/23.2.1\r
  34         (i486-pc-linux-gnu)\r
  35 Date: Thu, 27 Jan 2011 19:20:00 +0100\r
  36 Message-ID: <87fwsetdin.fsf@kepler.schwinge.homeip.net>\r
  37 MIME-Version: 1.0\r
  38 Content-Type: multipart/signed; boundary="=-=-=";\r
  39         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  40 X-Df-Sender: thomas@schwinge.name\r
  41 X-BeenThere: notmuch@notmuchmail.org\r
  42 X-Mailman-Version: 2.1.13\r
  43 Precedence: list\r
  44 List-Id: "Use and development of the notmuch mail system."\r
  45         <notmuch.notmuchmail.org>\r
  46 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  47         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  48 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  49 List-Post: <mailto:notmuch@notmuchmail.org>\r
  50 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  51 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  52         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  53 X-List-Received-Date: Thu, 27 Jan 2011 18:20:08 -0000\r
  54 \r
  55 --=-=-=\r
  56 Content-Type: text/plain; charset=utf-8\r
  57 Content-Transfer-Encoding: quoted-printable\r
  58 \r
  59 Hallo!\r
  60 \r
  61 Stepping away from the current code base -- what is notmuch's original\r
  62 idea of concurrency?  That is, all of us probably know that one:\r
  63 \r
  64     A Xapian exception occurred opening database: Unable to get write\r
  65       lock on /home/thomas/Mail-schwinge.name-thomas/.notmuch/xapian:\r
  66       already locked\r
  67 \r
  68 I recently saw that one while using the Emacs UI (that one tried to\r
  69 remove a unread tag or similar), and in parallel a delivery to the\r
  70 notmuch DB was going on.\r
  71 \r
  72 Apparently the DB we're using doesn't allow for simultaneous writing\r
  73 (even though it can't even possibly have been dangerous in this case).\r
  74 \r
  75 Which is the original idea here?  Is it that...\r
  76 \r
  77   * each and every client should catch these kinds of errors, and retry,\r
  78     or eventually give up at some point, and report the status to the\r
  79     user; or is it that...\r
  80 \r
  81   * notmuch internally should catch these concurrency cases, and retry,\r
  82     or eventually give up at some point (``notmuch --maximum-wait=3D30s tag\r
  83     [...]''), and fail as seen above?\r
  84 \r
  85 This one is an obvious temporary error due to a concurrency situation.\r
  86 Wouldn't the latter suggestion be preferable here?  I guess that in most\r
  87 cases the DB isn't locked for long periods of time, and thus the\r
  88 concurrency situation would decline quickly.\r
  89 \r
  90 \r
  91 One difficulty I see is judging which errors are temporary and which are\r
  92 permanent -- which is obvious in a lot of cases (concurrent DB access,\r
  93 memory starved or any other OS resource), but may not be, for example in\r
  94 case of I/O errors (is ``disk full'' a permanent error?).  And then, for\r
  95 some of these cases, waiting does make sense (concurrent DB access, as\r
  96 suggested above), and for other (temporary?) errors it doesn't make (a\r
  97 lot of) sense (out of memory: only sensible thing is to abort, and have\r
  98 the caller re-try, or disk full: waiting for some free space may be worth\r
  99 it, or it may be not).\r
 100 \r
 101 \r
 102 Gr=C3=BC=C3=9Fe,\r
 103  Thomas\r
 104 \r
 105 --=-=-=\r
 106 Content-Type: application/pgp-signature\r
 107 \r
 108 -----BEGIN PGP SIGNATURE-----\r
 109 Version: GnuPG v1.4.10 (GNU/Linux)\r
 110 \r
 111 iEYEARECAAYFAk1Bt1AACgkQFaWaPJ2HwArMKgCffq8V1+LF0cPw3Dnz6Mx1UkUg\r
 112 WuoAn08aUGKARifFx6GChSRpE/LtJlJj\r
 113 =xutB\r
 114 -----END PGP SIGNATURE-----\r
 115 --=-=-=--\r