Race condition for '*' command

[Carl Worth]

On Tue, 28 Jun 2011 11:36:10 -0600, Mark Anderson <ma.skies at gmail.com> wrote:
> On Tue, 28 Jun 2011 08:49:06 +0200, Pieter Praet <pieter at praet.org> wrote:
> > On Sun, 26 Jun 2011 10:00:41 +0100, Robin Green <greenrd at greenrd.org> wrote:
> > > On Sat, 25 Jun 2011 16:57:50 -0700, Jameson Graef Rollins <jrollins at finestructure.net> wrote:
> > > > On Sat, 25 Jun 2011 23:18:52 +0100, Robin Green <greenrd at greenrd.org> wrote:
> > > > > A race condition in the '*' command was noted when it was first
> > > > > proposed. It looks to me like it still exists - has anything been done
> > > > > about it?

Not much. I did add this note to notmuch/TODO at the time:

	Fix '*' to work by simply calling '+' or '-' on a region
	consisting of the entire buffer

> > Could be solved by doing it with `notmuch-search', `mark-whole-buffer'
> > and `notmuch-search-{add,remove}-tag-region' instead, but I'm sure
> > there's a better way (of which I'm as of yet unaware).

That's a more concrete description of the same idea.

I did some experiments at one point and determined that doing this would
make '*' far too painful to be usable with large search-result buffers,
(which is precisely when I am most likely to use it).

But even if we were willing to accept the performance penalty, (or if we
fixed notmuch-search-*-tag-region to accumulate the thread IDs and make
a single invocation of notmuch to avoid the performance penalty). Even
then, there would still be race conditions here, (though more subtle
than the current race).

At that point we would only be acting on threads that matched the
original search, but we could be acting on more messages than were
originally presented to the user.

For example, a thread might have been displayed as having only one post,
but the "* -inbox" operation would remove the inbox tag from any replies
received in the interim.

I'd love to find some clean solutions here, as I would love notmuch to
offer an interface that is free of these race conditions, (which are
scary since they can prevent a user from seeing some mail).

Personally, I'm avoiding all races right now by only running "notmuch
new" manually, (and not otherwise interacting with notmuch while
"notmuch new" is running). This does avoid the races, but is fairly
awkward, (I have to manually run this (or use the annoyingly blocking
'G'[*] binding), so I would prefer the ability to have new mail
incorporated automatically as it arrives.

Independent of this particular race condition, having something like
fetchmail automatically invoke "notmuch new" also has the potential to
break your mail client with Xapian Database-modified exceptions.

So we do need some more direct support for this mode of operation.

In the meantime, I've at least updated the TODO note a bit:

	Fix '*' to work by simply calling '+' or '-' on a region
	consisting of the entire buffer, (this would avoid one race
	condition---while still leaving other race conditions---but
	could also potentially make '*' a very expensive operation).

-Carl

[*] notmuch-search-poll-and-refresh-view

-- 
carl.d.worth at intel.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110628/b2a5ff0f/attachment.pgp>