Re: [PATCH 2/2] [RFC] possible solution for "Race condition for '*' command"
authorPieter Praet <pieter@praet.org>
Sat, 2 Jul 2011 14:20:39 +0000 (16:20 +0200)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:38:55 +0000 (09:38 -0800)
13/d9b41c2ce7272c3de358469d394c983975a82c [new file with mode: 0644]

diff --git a/13/d9b41c2ce7272c3de358469d394c983975a82c b/13/d9b41c2ce7272c3de358469d394c983975a82c
new file mode 100644 (file)
index 0000000..521c9f8
--- /dev/null
@@ -0,0 +1,126 @@
+Return-Path: <pieter@praet.org>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id 02B16429E25\r
+       for <notmuch@notmuchmail.org>; Sat,  2 Jul 2011 07:20:45 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+       tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id xIr6vvzGkZeU for <notmuch@notmuchmail.org>;\r
+       Sat,  2 Jul 2011 07:20:44 -0700 (PDT)\r
+Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com\r
+       [74.125.82.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
+       (No client certificate requested)\r
+       by olra.theworths.org (Postfix) with ESMTPS id A0B41431FD0\r
+       for <notmuch@notmuchmail.org>; Sat,  2 Jul 2011 07:20:44 -0700 (PDT)\r
+Received: by wyh22 with SMTP id 22so3070359wyh.26\r
+       for <notmuch@notmuchmail.org>; Sat, 02 Jul 2011 07:20:43 -0700 (PDT)\r
+Received: by 10.227.156.70 with SMTP id v6mr3876933wbw.21.1309616443125;\r
+       Sat, 02 Jul 2011 07:20:43 -0700 (PDT)\r
+Received: from localhost (91.216-242-81.adsl-dyn.isp.belgacom.be\r
+       [81.242.216.91])\r
+       by mx.google.com with ESMTPS id fp5sm1811256wbb.66.2011.07.02.07.20.40\r
+       (version=TLSv1/SSLv3 cipher=OTHER);\r
+       Sat, 02 Jul 2011 07:20:41 -0700 (PDT)\r
+From: Pieter Praet <pieter@praet.org>\r
+To: Austin Clements <amdragon@mit.edu>\r
+Subject: Re: [PATCH 2/2] [RFC] possible solution for "Race condition for '*'\r
+       command"\r
+In-Reply-To:\r
+ <CAH-f9WticM4EN8F1_ik_-mcBcBtrXwSpO+Drbtp7=UN7McECrg@mail.gmail.com>\r
+References:\r
+ <CAH-f9WticM4EN8F1_ik_-mcBcBtrXwSpO+Drbtp7=UN7McECrg@mail.gmail.com>\r
+User-Agent: Notmuch/0.5-315-g34bd5eb (http://notmuchmail.org) Emacs/23.1.50.1\r
+       (x86_64-pc-linux-gnu)\r
+Date: Sat, 02 Jul 2011 16:20:39 +0200\r
+Message-ID: <87zkkwydag.fsf@praet.org>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=us-ascii\r
+Cc: notmuch@notmuchmail.org\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sat, 02 Jul 2011 14:20:46 -0000\r
+\r
+On Fri, 1 Jul 2011 12:37:11 -0400, Austin Clements <amdragon@mit.edu> wrote:\r
+Non-text part: multipart/alternative\r
+> On Jul 1, 2011 10:55 AM, "Austin Clements" <amdragon@mit.edu> wrote:\r
+> >\r
+> > On Thu, Jun 30, 2011 at 3:38 PM, Pieter Praet <pieter@praet.org> wrote:\r
+> > > Ok, even though my very first reply [1] may have created the impression\r
+> > > that I understood the issue, I clearly didn't...\r
+> > >\r
+> > > The test [2] needs a more applicable commit message, and the subsequent\r
+> > > patch [3] points more or less in the right direction, but the Message-Id\r
+> > > list should be local to the *search buffer* rather than to the\r
+> > > `notmuch-search-operate-all' function.\r
+> > >\r
+> > > `notmuch-search' could:\r
+> > >  - run "notmuch-command search" with the "--output=messages" option\r
+> > >    instead of a plain search,\r
+> > >  - maintain a buffer-local var with a list of returned Message-Id's,\r
+> > >  - ...and populate the buffer based on that list.\r
+> > >\r
+> > > As such we'd have -for each individual search buffer- a canonical list\r
+> > > of Message-Id's (i.e. messages which actually *match* the query AND are\r
+> > > currently visible in the search buffer), to be used by\r
+> > > `notmuch-search-operate-all' et al.\r
+> > >\r
+> > >\r
+> > > Peace\r
+> > >\r
+> > > --\r
+> > > Pieter\r
+> > >\r
+> > > [1] id:"87fwmuxxgd.fsf@praet.org"\r
+> > > [2] id:"1309450108-2793-2-git-send-email-pieter@praet.org"\r
+> > > [3] id:"1309450108-2793-1-git-send-email-pieter@praet.org"\r
+> >\r
+> > Ideally, this wouldn't be per-buffer, but per *line*.  This race\r
+> > equally affects adding and removing tags from individual results,\r
+> > since that's done using a thread: query, whose results could have\r
+> > changed since the original search.\r
+> >\r
+> > This almost certainly requires support from the notmuch core.  The\r
+> > good news is that the library already provides this information, so\r
+> > there will be virtually no performance hit for outputting it.\r
+> \r
+> Actually, with a smidgeon of library support, you could even use document\r
+> IDs for this, rather than message IDs, which would make the tagging\r
+> operations (even '*') no more expensive than they are now.  (Of course, it\r
+> would be good to know just how much overhead going through message IDs\r
+> actually introduces.)\r
+Non-text part: text/html\r
+\r
+\r
+That would be awesome!\r
+\r
+Though I'd rather leave the plumbing to someone sufficiently capable,\r
+so, if leaving libnotmuch hacking out of the equation, how would one go\r
+about doing this?\r
+\r
+I (ignorantly) assume we'd get `notmuch-search-process-filter'\r
+to append each line with an invisible field containing a list\r
+of matching Message-Id's, presumably obtained via\r
+`notmuch_thread_get_matched_messages' (@ lib/thread.cc) ?\r
+\r
+\r
+Peace\r
+\r
+-- \r
+Pieter\r