[PATCH 00/10] Fix 'notmuch new' atomicity issues

[Carl Worth]

On Fri, 10 Jun 2011 17:11:03 -0400, Austin Clements <amdragon at MIT.EDU> wrote:
> Mm.  It's now remove_filename (could be remove_message_filename?)

I like remove_filename just fine. Thanks.

> I've pushed the easy changes as atomic-new-v5, mostly to get them in
> the record.

Thanks. I'll look. These should all be ready to push with the
discussion-pending stuff to come?

> But, maybe they sharpen it in the wrong direction.  An alternate way
> to look at this is that a message is a single file that can also tell
> you file names that contain equivalent messages.  This might be more
> of a mindset (or documentation change) than an actual API change; I'm
> not sure.  It certainly fits better with the existing
> {add,remove}_message, but it's not clear if that's intentional or
> historical.  Thoughts?

That seems to match what I had in mind when I designed the original
{add,remove}_message, yes. So I'm interested in running with this to see
if we can't make it work.

One trick is that most of the early design was done by me in a
vacuum. I think we're fortunate to now have a wider community to help
catch design mistakes of mine.

> >   * Can we fix the remove case without this new library API by simply
> >     adding calls to begin_atomic and end_atomic?
> > 
> >     I think this is probably the solution I would prefer to see.
> > 
> > What do you think, Austin?
> 
> Of these three, I would definitely go with the last.

Good. We're thinking along the same lines at least.

> That last reason is also compatible with your last suggestion.  If we
> move to atomic sections, I think we have to make sure the library
> never internally violates atomicity and that the library user only
> needs to use atomic sections directly if they need atomicity across
> multiple library calls.  This shouldn't be hard, especially with
> nested atomics.

Thanks for providing so much of your rationale. The constraint you
describe here sounds perfect. With the library respecting this, it seems
it would make it very easy for anyone reviewing notmuch-new.c (or
implementing something similar from scratch) to correctly identify the
spots that need begin_atomic/end_atomic.

> I'll give this a try and see where it leads.

I'm looking forward to what you come up with.[*]

-Carl

[*] To satisfy grammarian pedantism—A preposition (let alone two) is
something you should never end a sentence with—I might offer:

	I'm looking forward to that with which you up will come.

-- 
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/20110610/32052fc5/attachment.pgp>