unofficial mirror of notmuch@notmuchmail.org
 help / color / mirror / code / Atom feed
From: David Bremner <david@tethera.net>
To: Floris Bruynooghe <flub@devork.be>, notmuch@notmuchmail.org
Subject: Re: Usage after database close
Date: Sun, 28 Jun 2020 13:19:45 -0300	[thread overview]
Message-ID: <87d05jkvry.fsf@tethera.net> (raw)
In-Reply-To: <87d05je1j6.fsf@powell.devork.be>

Floris Bruynooghe <flub@devork.be> writes:

> Hi,
>
> I started writing some test cases to define better what you can do with
> a closed database and make sure that the python bindings do not behave
> unexpectedly here too.
>
> One of the first things I tried ends up with xapian calling
> exit_group(2) directly, terminating the process.  So I'm wondering if
> I'm approaching this entirely the wrong way.  My understanding is that
> we should generally be allowed to use anything after the database has
> been closed, as long as nothing has been destroyed.
>
> Below is a minimal reproducible example of what I'm testing so far.  I
> must admit I'm generally lazy here and usually just test with notmuch
> that is currently in Debian testing.

Funny that you should mention lazy, that's basically what the problem is
here ;). notmuch_message_get_message_id is lazily trying to read the
information from the database. This is a bit surprising here because of
the query, but that's not really visible once the message object is
created.

In principle it could be documented what parts of the API can trigger
access to the database, but I'm not sure about the benefit of the extra
complexity. It might be safer to assume that only access to already
fetched information is safe. In particular if you move

    messageid = notmuch_message_get_message_id(msg);

before you close the database, then printing it out afterwards works. I
didn't run it valgrind to make sure, but afaik, that should be perfectly
legal.

The original motivation (see 7864350c938944276c1a378539da7670c211b9b5)
to allow long running processes to release the lock on the
database. This is not a pattern we use in the CLI, so it's not as well
tested as it could be. In particular the work to export
notmuch_database_reopen (tests, documentation) has not happened yet.

d

  reply	other threads:[~2020-06-28 16:19 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-28 13:57 Usage after database close Floris Bruynooghe
2020-06-28 16:19 ` David Bremner [this message]
2020-06-28 20:47   ` Floris Bruynooghe
2020-06-28 22:11     ` David Bremner
2020-06-28 22:24       ` David Bremner
2020-06-29 14:39         ` David Bremner
2020-06-29 21:18       ` Floris Bruynooghe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://notmuchmail.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d05jkvry.fsf@tethera.net \
    --to=david@tethera.net \
    --cc=flub@devork.be \
    --cc=notmuch@notmuchmail.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://yhetil.org/notmuch.git/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).