David Bremner <david@tethera.net> writes:

> The error handling here still needs work. The retry count should be
> handled in more sane way, and both running out of retries and an error
> return from notmuch_database_reopen should be handled.

Probably the number of retries can be limited to 1, since afaict, reopen
is not going to return any recoverable errors.

Gaute's test program seems run to completion without any source
modifications.

One general comment about this approach is that it does not do anything
about any the metadata that may be cached by notmuch for other
messages. Roughly speaking the behaviour should be atomic with respect
to messages, but not e.g. within threads. A message read earlier may not
reflect changes seen in a later one. That potential inconsistency would
only occur in cases currently resulting in crashes.

It is possible there is some scheme we can use to invalidate all of the
cached metadata. Here's an initial idea. The notmuch_database_t object
keeps a counter/timestamp which indicates the last time it was
invalidated. Each message object has a counter/timestamp indicating the
last time it it was synced/validated. Instead of checking if some
pointer is null force a read, we'd have to compare these two counters. I
think the main counter could be set to zero by database_open and
incremented by database_reopen