71/04c7e75975c7dd2b2a78e01ba28d078436f0d1

   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 2536E431FB6\r
   6         for <notmuch@notmuchmail.org>; Fri,  9 Nov 2012 21:29:53 -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.7\r
  10 X-Spam-Level: \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 l7LoA5VohaN4 for <notmuch@notmuchmail.org>;\r
  16         Fri,  9 Nov 2012 21:29:51 -0800 (PST)\r
  17 Received: from dmz-mailsec-scanner-5.mit.edu (DMZ-MAILSEC-SCANNER-5.MIT.EDU\r
  18         [18.7.68.34])\r
  19         by olra.theworths.org (Postfix) with ESMTP id 03E3F431FAE\r
  20         for <notmuch@notmuchmail.org>; Fri,  9 Nov 2012 21:29:50 -0800 (PST)\r
  21 X-AuditID: 12074422-b7f746d0000008cc-62-509de64e33f1\r
  22 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35])\r
  23         by dmz-mailsec-scanner-5.mit.edu (Symantec Messaging Gateway) with SMTP\r
  24         id 9F.33.02252.E46ED905; Sat, 10 Nov 2012 00:29:50 -0500 (EST)\r
  25 Received: from outgoing.mit.edu (OUTGOING-AUTH.MIT.EDU [18.7.22.103])\r
  26         by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id qAA5TnpI014822; \r
  27         Sat, 10 Nov 2012 00:29:50 -0500\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 qAA5Tl59008088\r
  32         (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT);\r
  33         Sat, 10 Nov 2012 00:29:49 -0500 (EST)\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 1TX3db-0000pf-J4; Sat, 10 Nov 2012 00:29:47 -0500\r
  37 Date: Sat, 10 Nov 2012 00:29:47 -0500\r
  38 From: Austin Clements <amdragon@MIT.EDU>\r
  39 To: Mark Walters <markwalters1009@gmail.com>\r
  40 Subject: Re: [PATCH 0/3] Outline fix for emacs tagging race\r
  41 Message-ID: <20121110052947.GK22284@mit.edu>\r
  42 References: <1352487491-31512-1-git-send-email-markwalters1009@gmail.com>\r
  43 MIME-Version: 1.0\r
  44 Content-Type: text/plain; charset=us-ascii\r
  45 Content-Disposition: inline\r
  46 In-Reply-To: <1352487491-31512-1-git-send-email-markwalters1009@gmail.com>\r
  47 User-Agent: Mutt/1.5.21 (2010-09-15)\r
  48 X-Brightmail-Tracker:\r
  49  H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42IR4hRV1vV7NjfAYMsMcYvVc3ksrt+cyezA\r
  50         5LFz1l12j2erbjEHMEVx2aSk5mSWpRbp2yVwZew5f4W14LB8xa+bKxkbGGdLdjFyckgImEjs\r
  51         mbOeEcIWk7hwbz1bFyMXh5DAPkaJzq3XGSGcDYwSR37/ZoZwTjJJdF/fyQrhLGGUmP1oKVg/\r
  52         i4CqxOYdb8BsNgENiW37l4PZIgI6ErcPLWAHsZkFpCW+/W5mArGFBawl3t79D1bDC1Qzd9lx\r
  53         ZhBbSMBTYk3TCzaIuKDEyZlPWCB6tSRu/HsJ1MsBNmf5Pw6QMKeAl8TL06/AykUFVCSmnNzG\r
  54         NoFRaBaS7llIumchdC9gZF7FKJuSW6Wbm5iZU5yarFucnJiXl1qka6qXm1mil5pSuokRFNbs\r
  55         Lko7GH8eVDrEKMDBqMTDmxA+N0CINbGsuDL3EKMkB5OSKO/PJ0AhvqT8lMqMxOKM+KLSnNTi\r
  56         Q4wSHMxKIryv+oFyvCmJlVWpRfkwKWkOFiVx3mspN/2FBNITS1KzU1MLUotgsjIcHEoSvIVP\r
  57         gRoFi1LTUyvSMnNKENJMHJwgw3mAhseA1PAWFyTmFmemQ+RPMepyHH0z9yGjEEtefl6qlDiv\r
  58         D0iRAEhRRmke3BxYOnrFKA70ljBvIkgVDzCVwU16BbSECWhJ45E5IEtKEhFSUg2MRZ1vb+yp\r
  59         +v2mgV1LtbT/tNq+bbmuOttDFevMa2Z+lFe+Wfl4xopNXkozVQ6EZ78KdpRbc7Ihw7pIZ29p\r
  60         0mrd0yeW/sufa7I3aEfMUZlHp37zHucNsr97e86FUKcZO1xtOP18Shu877Wqu8gzaJveesnl\r
  61         uXm26+FQuWs8zDc4VjO+NtMRM9iixFKckWioxVxUnAgAATH5siIDAAA=\r
  62 Cc: notmuch@notmuchmail.org\r
  63 X-BeenThere: notmuch@notmuchmail.org\r
  64 X-Mailman-Version: 2.1.13\r
  65 Precedence: list\r
  66 List-Id: "Use and development of the notmuch mail system."\r
  67         <notmuch.notmuchmail.org>\r
  68 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  69         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  70 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  71 List-Post: <mailto:notmuch@notmuchmail.org>\r
  72 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  73 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  74         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  75 X-List-Received-Date: Sat, 10 Nov 2012 05:29:53 -0000\r
  76 \r
  77 Quoth Mark Walters on Nov 09 at  6:58 pm:\r
  78 > For a long time [1] there have been two related races in tagging from\r
  79 > the search buffer.\r
  80 > \r
  81 > The first is that when tagging (including archiving) a thread message\r
  82 > which arrived after the buffer was created may also be tagged. This is\r
  83 > because the tagging is done based on the thread-id not on the\r
  84 > individual messages.\r
  85 > \r
  86 > The second is when using the '*' command to tag all messages. This is\r
  87 > not quite the same as this command only tags messages matching the\r
  88 > query not all messages in all threads that contain a message matching\r
  89 > the query. Thus if more messages now match than when the buffer was\r
  90 > created (eg some external tagging script has run) then this command\r
  91 > can unexpectedly tag these messages too.\r
  92 > \r
  93 > One solution that was discussed in [2] was for the search output of\r
  94 > notmuch to include the message-ids of both matching and non-matching\r
  95 > messages. At that time that was difficult to implement as it was\r
  96 > unclear how to escape the message ids when using the text\r
  97 > format. Since emacs now uses JSON for search mode this problem is\r
  98 > solved.\r
  99 > \r
 100 > This patch series implements the above mentioned solution and seems to\r
 101 > work except for one problem.\r
 102 > \r
 103 > Since emacs now tags each message in a thread in the search buffer it\r
 104 > is easy to ask it to tag a lot of messages. This could be done\r
 105 > individually which would be ridiculously slow so instead they are all\r
 106 > done in one batch. But now it is relatively easy to take notmuch over\r
 107 > the threshold for ARG_MAX.\r
 108 > \r
 109 > In [3] Tomi did some experiments and found on a standard Debian system\r
 110 > with getconf ARG_MAX =131072 that command lines with 10000 200 byte\r
 111 > arguments worked. I am a little puzzled by that as I get the same\r
 112 > results and I getconf ARG_MAX gives 2097152 for me.\r
 113 > \r
 114 > More importantly though, when trying to execute a command from emacs I\r
 115 > am finding that 131072 is the limit on the command length in bytes and\r
 116 > we can hit this with something around 1500 messages (see end for a\r
 117 > very hacky emacs test script). This is probably more than we can\r
 118 > expect in a single thread so tagging from show is probably safe but it\r
 119 > does cause a problem when tagging from search.\r
 120 > \r
 121 > I can think of several possible solutions (e.g., batch it in my new\r
 122 > stuff, put some batching in notmuch-tag, all notmuch tag to read a\r
 123 > query from stdin). But before any larger more intrusive change do\r
 124 > people like the general approach? Does anyone have a good way to get\r
 125 > round the command line size problem?\r
 126 > \r
 127 > Best wishes \r
 128 > \r
 129 > Mark\r
 130 > \r
 131 > \r
 132 > [1] id:87ocmtg9ni.fsf@yoom.home.cworth.org\r
 133 > [2] id:CAH-f9WticM4EN8F1_ik_-mcBcBtrXwSpO+Drbtp7=UN7McECrg@mail.gmail.com\r
 134 > [3] id:m2liody7av.fsf@guru.guru-group.fi\r
 135 \r
 136 I'm glad to see someone picking up this bug.  Besides somehow dealing\r
 137 with long command-lines, when we were last exploring this race, I had\r
 138 found that it was 3-4x more efficient to use Xapian document IDs\r
 139 directly rather than message IDs [1].  It's probably best *not* to do\r
 140 this initially for the sake of simplicity, but I think a simple tweak\r
 141 to your approach would let us seamlessly transition to this in the\r
 142 future.  Rather than extending the JSON output with what are\r
 143 explicitly message IDs, instead extend the output with opaque queries\r
 144 that are guaranteed to match the matching/non-matching messages in the\r
 145 thread and are guaranteed to be combinable, but aren't guaranteed to\r
 146 be of any particular form.  For now, the CLI can simply output id:\r
 147 queries for these, but in the future we could easily add a special\r
 148 query syntax for docid queries or, if we ever move to a custom query\r
 149 parser, support docids in any query.\r
 150 \r
 151 For the long command line problem, one easy solution is to support,\r
 152 say, '-' as a query syntax that means "read the query from stdin."\r
 153 This would be a simple addition to query_string_from_args and would\r
 154 work across the CLI.\r
 155 \r
 156 [1] id:CAH-f9WsPj=1Eu=g3sOePJgCTBFs6HrLdLq18xMEnJ8aZ00yCEg@mail.gmail.com\r