Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id BC12041ED96 for ; Fri, 1 Jul 2011 09:37:13 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.698 X-Spam-Level: X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tLznxgu3mZr for ; Fri, 1 Jul 2011 09:37:12 -0700 (PDT) Received: from mail-qy0-f181.google.com (mail-qy0-f181.google.com [209.85.216.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id B040441ED8C for ; Fri, 1 Jul 2011 09:37:12 -0700 (PDT) Received: by qyk9 with SMTP id 9so2248310qyk.5 for ; Fri, 01 Jul 2011 09:37:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=M2SN8lXY5a8KsS1KTGJxjEFHyAxUzZUeyhcWllEgVZI=; b=mobY+Ckbss5v885pGUA8fSFV5ETNhvefZjOvzXQkA7w90XlzB2x6lnfsMbZTUgM2es oFwcxshMTT2OQQkfB0HQld4pZnHu51oeZwVJb1uvTNZoA45MMArNXdE138oyKQ9k2QU3 OpJRRqmLCpm0gx6K1VL3n248I9jbpF6nI+zsU= MIME-Version: 1.0 Received: by 10.229.2.89 with SMTP id 25mr2702766qci.39.1309538231775; Fri, 01 Jul 2011 09:37:11 -0700 (PDT) Sender: amdragon@gmail.com Received: by 10.229.249.193 with HTTP; Fri, 1 Jul 2011 09:37:11 -0700 (PDT) Received: by 10.229.249.193 with HTTP; Fri, 1 Jul 2011 09:37:11 -0700 (PDT) Date: Fri, 1 Jul 2011 12:37:11 -0400 X-Google-Sender-Auth: t2iRJO4tosjFqsllPWskVp_-RUg Message-ID: Subject: Re: [PATCH 2/2] [RFC] possible solution for "Race condition for '*' command" From: Austin Clements To: Austin Clements Content-Type: multipart/alternative; boundary=00148537ab781ff39f04a704a101 Cc: notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Jul 2011 16:37:14 -0000 --00148537ab781ff39f04a704a101 Content-Type: text/plain; charset=ISO-8859-1 On Jul 1, 2011 10:55 AM, "Austin Clements" wrote: > > On Thu, Jun 30, 2011 at 3:38 PM, Pieter Praet wrote: > > Ok, even though my very first reply [1] may have created the impression > > that I understood the issue, I clearly didn't... > > > > The test [2] needs a more applicable commit message, and the subsequent > > patch [3] points more or less in the right direction, but the Message-Id > > list should be local to the *search buffer* rather than to the > > `notmuch-search-operate-all' function. > > > > `notmuch-search' could: > > - run "notmuch-command search" with the "--output=messages" option > > instead of a plain search, > > - maintain a buffer-local var with a list of returned Message-Id's, > > - ...and populate the buffer based on that list. > > > > As such we'd have -for each individual search buffer- a canonical list > > of Message-Id's (i.e. messages which actually *match* the query AND are > > currently visible in the search buffer), to be used by > > `notmuch-search-operate-all' et al. > > > > > > Peace > > > > -- > > Pieter > > > > [1] id:"87fwmuxxgd.fsf@praet.org" > > [2] id:"1309450108-2793-2-git-send-email-pieter@praet.org" > > [3] id:"1309450108-2793-1-git-send-email-pieter@praet.org" > > Ideally, this wouldn't be per-buffer, but per *line*. This race > equally affects adding and removing tags from individual results, > since that's done using a thread: query, whose results could have > changed since the original search. > > This almost certainly requires support from the notmuch core. The > good news is that the library already provides this information, so > there will be virtually no performance hit for outputting it. Actually, with a smidgeon of library support, you could even use document IDs for this, rather than message IDs, which would make the tagging operations (even '*') no more expensive than they are now. (Of course, it would be good to know just how much overhead going through message IDs actually introduces.) --00148537ab781ff39f04a704a101 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Jul 1, 2011 10:55 AM, "Austin Clements" <amdragon@mit.edu> wrote:
>
> On Thu, Jun 30, 2011 at 3:38 PM, Pieter Praet <pieter@praet.org> wrote:
> > Ok, even though my very first reply [1] may have created the impr= ession
> > that I understood the issue, I clearly didn't...
> >
> > The test [2] needs a more applicable commit message, and the subs= equent
> > patch [3] points more or less in the right direction, but the Mes= sage-Id
> > list should be local to the *search buffer* rather than to the > > `notmuch-search-operate-all' function.
> >
> > `notmuch-search' could:
> > =A0- run "notmuch-command search" with the "--outp= ut=3Dmessages" option
> > =A0 =A0instead of a plain search,
> > =A0- maintain a buffer-local var with a list of returned Message-= Id's,
> > =A0- ...and populate the buffer based on that list.
> >
> > As such we'd have -for each individual search buffer- a canon= ical list
> > of Message-Id's (i.e. messages which actually *match* the que= ry AND are
> > currently visible in the search buffer), to be used by
> > `notmuch-search-operate-all' et al.
> >
> >
> > Peace
> >
> > --
> > Pieter
> >
> > [1] id:"87fwmuxx= gd.fsf@praet.org"
> > [2] id:"1309450108-2793-2-git-send-email-pieter@praet.org"= ;
> > [3] id:"1309450108-2793-1-git-send-email-pieter@praet.org"= ;
>
> Ideally, this wouldn't be per-buffer, but per *line*. =A0This race=
> equally affects adding and removing tags from individual results,
> since that's done using a thread: query, whose results could have<= br> > changed since the original search.
>
> This almost certainly requires support from the notmuch core. =A0The > good news is that the library already provides this information, so > there will be virtually no performance hit for outputting it.

Actually, with a smidgeon of library support, you could even use documen= t IDs for this, rather than message IDs, which would make the tagging opera= tions (even '*') no more expensive than they are now.=A0 (Of course= , it would be good to know just how much overhead going through message IDs= actually introduces.)

--00148537ab781ff39f04a704a101--