On Mon 15 Jun 2020 at 07:35 -0300, David Bremner wrote: > Floris Bruynooghe <f...@devork.be> writes: > >> This is an implementation of what was suggested in >> id:87v9k96xtl....@powell.devork.be It closes the database as that is >> the only safe way to do this afaik. >> >> Currently when the database is closed there are still a bunch of >> operations which can result in segfaults.
I realise that this is perhaps not a very helpful comment. I'll see if I can narrow this down into a proper bug report. >> Yet the API also promises >> that some operations are still valid, basically those which only >> access already previously retrieved information. It would be nice to >> find a good solution for this in the python bindings, but I don't yet >> know what this would be. > > There is a Xapian method WritableDatabase::cancel_transaction(), but it > is not currently exposed by notmuch. I think it could be added, but > getting the testing working right is not something I want to tackle at > this point in the release cycle. I guess this should be upwardly > compatible, as all code correct for your current implementation should > still work if we replace notmuch_database_close with > notmuch_cancel_atomic. Thoughts? I agree with your reasoning here that such a change would be upwardly compatible. Though I can think of some really convoluted scenarios where this could be false, e.g. after aborting a transaction code could rely on handling NOTMUCH_STATUS_XAPIAN_EXCEPTION it gets from a the closed database. This seems so much a corner case though, that I'd be willing to ignore it. _______________________________________________ notmuch mailing list email@example.com https://notmuchmail.org/mailman/listinfo/notmuch