[PATCH 2/2] [RFC] possible solution for "Race condition for '*' command"

[Austin Clements]

On Jul 1, 2011 10:55 AM, "Austin Clements" <amdragon at mit.edu> wrote:
>
> On Thu, Jun 30, 2011 at 3:38 PM, Pieter Praet <pieter at praet.org> 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 at praet.org"
> > [2] id:"1309450108-2793-2-git-send-email-pieter at praet.org"
> > [3] id:"1309450108-2793-1-git-send-email-pieter at 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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110701/b66038b3/attachment.html>