d2/5baad321e5efaf6d14ec4454fad334116d82eb

   1 Return-Path: <markwalters1009@gmail.com>\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 678C0431FB6\r
   6         for <notmuch@notmuchmail.org>; Fri,  9 Nov 2012 10:58:27 -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.201\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0.201 tagged_above=-999 required=5\r
  12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
  13         FREEMAIL_ENVFROM_END_DIGIT=1, FREEMAIL_FROM=0.001,\r
  14         RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
  15 Received: from olra.theworths.org ([127.0.0.1])\r
  16         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  17         with ESMTP id pp1zC4URjimz for <notmuch@notmuchmail.org>;\r
  18         Fri,  9 Nov 2012 10:58:25 -0800 (PST)\r
  19 Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com\r
  20  [74.125.82.45])        (using TLSv1 with cipher RC4-SHA (128/128 bits))        (No client\r
  21  certificate requested) by olra.theworths.org (Postfix) with ESMTPS id\r
  22  34FC2431FAE    for <notmuch@notmuchmail.org>; Fri,  9 Nov 2012 10:58:25 -0800\r
  23  (PST)\r
  24 Received: by mail-wg0-f45.google.com with SMTP id dq12so2288423wgb.2\r
  25         for <notmuch@notmuchmail.org>; Fri, 09 Nov 2012 10:58:23 -0800 (PST)\r
  26 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;\r
  27         h=from:to:cc:subject:date:message-id:x-mailer;\r
  28         bh=iVqVh7xUHX1VPSG0tXROjHgC34l3GXEyAxVmiyl7UI0=;\r
  29         b=Ak3HOehNKJA4AqbhdaDgL2jJXzmlmY2BcR9rJT3FaFviPiWvvZuP682qIxK95qn6CG\r
  30         UTX29l7j1NhYK3vEbn2/Pq/rISpq2y/uFas3qhllSf1AoIs/v1Nejsvh0JOZ+/CwW4gx\r
  31         ZN49TadE0ISl8JOfs4n1jxbBdxom3TSEOpJKUwPmOIlikGBRG9ber0I6uh41CTuDXb+l\r
  32         Nm8/sCg6vWjnffYSs3eAL5OCxKnenoXJsaS2RItEJI206B1XiPqtuKeArOcpMjlOcyDR\r
  33         A7gesBy05x79a8fafBJlr+XiIpjBBfO3Lp9p7OpRT/CJmh0M5ZTPKKjgaxK6Dd1jqYRX\r
  34         IUhQ==\r
  35 Received: by 10.180.95.201 with SMTP id dm9mr4184109wib.3.1352487502655;\r
  36         Fri, 09 Nov 2012 10:58:22 -0800 (PST)\r
  37 Received: from localhost (93-97-24-31.zone5.bethere.co.uk. [93.97.24.31])\r
  38         by mx.google.com with ESMTPS id r10sm3779351wiz.0.2012.11.09.10.58.20\r
  39         (version=TLSv1/SSLv3 cipher=OTHER);\r
  40         Fri, 09 Nov 2012 10:58:21 -0800 (PST)\r
  41 From: Mark Walters <markwalters1009@gmail.com>\r
  42 To: notmuch@notmuchmail.org\r
  43 Subject: [PATCH 0/3] Outline fix for emacs tagging race\r
  44 Date: Fri,  9 Nov 2012 18:58:08 +0000\r
  45 Message-Id: <1352487491-31512-1-git-send-email-markwalters1009@gmail.com>\r
  46 X-Mailer: git-send-email 1.7.9.1\r
  47 X-BeenThere: notmuch@notmuchmail.org\r
  48 X-Mailman-Version: 2.1.13\r
  49 Precedence: list\r
  50 List-Id: "Use and development of the notmuch mail system."\r
  51         <notmuch.notmuchmail.org>\r
  52 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  53         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  54 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  55 List-Post: <mailto:notmuch@notmuchmail.org>\r
  56 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  57 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  58         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  59 X-List-Received-Date: Fri, 09 Nov 2012 18:58:27 -0000\r
  60 \r
  61 For a long time [1] there have been two related races in tagging from\r
  62 the search buffer.\r
  63 \r
  64 The first is that when tagging (including archiving) a thread message\r
  65 which arrived after the buffer was created may also be tagged. This is\r
  66 because the tagging is done based on the thread-id not on the\r
  67 individual messages.\r
  68 \r
  69 The second is when using the '*' command to tag all messages. This is\r
  70 not quite the same as this command only tags messages matching the\r
  71 query not all messages in all threads that contain a message matching\r
  72 the query. Thus if more messages now match than when the buffer was\r
  73 created (eg some external tagging script has run) then this command\r
  74 can unexpectedly tag these messages too.\r
  75 \r
  76 One solution that was discussed in [2] was for the search output of\r
  77 notmuch to include the message-ids of both matching and non-matching\r
  78 messages. At that time that was difficult to implement as it was\r
  79 unclear how to escape the message ids when using the text\r
  80 format. Since emacs now uses JSON for search mode this problem is\r
  81 solved.\r
  82 \r
  83 This patch series implements the above mentioned solution and seems to\r
  84 work except for one problem.\r
  85 \r
  86 Since emacs now tags each message in a thread in the search buffer it\r
  87 is easy to ask it to tag a lot of messages. This could be done\r
  88 individually which would be ridiculously slow so instead they are all\r
  89 done in one batch. But now it is relatively easy to take notmuch over\r
  90 the threshold for ARG_MAX.\r
  91 \r
  92 In [3] Tomi did some experiments and found on a standard Debian system\r
  93 with getconf ARG_MAX =131072 that command lines with 10000 200 byte\r
  94 arguments worked. I am a little puzzled by that as I get the same\r
  95 results and I getconf ARG_MAX gives 2097152 for me.\r
  96 \r
  97 More importantly though, when trying to execute a command from emacs I\r
  98 am finding that 131072 is the limit on the command length in bytes and\r
  99 we can hit this with something around 1500 messages (see end for a\r
 100 very hacky emacs test script). This is probably more than we can\r
 101 expect in a single thread so tagging from show is probably safe but it\r
 102 does cause a problem when tagging from search.\r
 103 \r
 104 I can think of several possible solutions (e.g., batch it in my new\r
 105 stuff, put some batching in notmuch-tag, all notmuch tag to read a\r
 106 query from stdin). But before any larger more intrusive change do\r
 107 people like the general approach? Does anyone have a good way to get\r
 108 round the command line size problem?\r
 109 \r
 110 Best wishes \r
 111 \r
 112 Mark\r
 113 \r
 114 \r
 115 [1] id:87ocmtg9ni.fsf@yoom.home.cworth.org\r
 116 [2] id:CAH-f9WticM4EN8F1_ik_-mcBcBtrXwSpO+Drbtp7=UN7McECrg@mail.gmail.com\r
 117 [3] id:m2liody7av.fsf@guru.guru-group.fi\r
 118 \r
 119 Mark Walters (3):\r
 120   test: test for race when tagging from emacs search\r
 121   cli: all search mode to include msg-ids with JSON output\r
 122   emacs: make emacs use message-ids for tagging\r
 123 \r
 124  emacs/notmuch.el |   22 ++++++++++++++++++++--\r
 125  notmuch-search.c |   40 ++++++++++++++++++++++++++++++++++++++--\r
 126  test/emacs       |   21 +++++++++++++++++++++\r
 127  3 files changed, 79 insertions(+), 4 deletions(-)\r
 128 \r
 129 \r
 130 TEST SCRIPT\r
 131 \r
 132 (progn\r
 133   (setq bigstring "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa")\r
 134   (setq n 1310)\r
 135   (setq big nil)\r
 136   (while (> n 0)\r
 137     (setq n (1- n))\r
 138     (setq big (concat big (format "%s" n) " " bigstring)))\r
 139   (call-process "echo" nil t nil big))\r
 140 \r
 141 \r
 142 \r
 143 -- \r
 144 1.7.9.1\r
 145 \r