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 _______________________________________________ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch