From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp0 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id cIE7D0TS516uGgAA0tVLHw (envelope-from ) for ; Mon, 15 Jun 2020 19:55:48 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp0 with LMTPS id gGoKC0TS517MYAAA1q6Kng (envelope-from ) for ; Mon, 15 Jun 2020 19:55:48 +0000 Received: from arlo.cworth.org (arlo.cworth.org [50.126.95.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 418F0940704 for ; Mon, 15 Jun 2020 19:55:45 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 880006DE0F46; Mon, 15 Jun 2020 12:55:41 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nyoC7kWxoyMH; Mon, 15 Jun 2020 12:55:41 -0700 (PDT) Received: from arlo.cworth.org (localhost [IPv6:::1]) by arlo.cworth.org (Postfix) with ESMTP id 621CE6DE0A43; Mon, 15 Jun 2020 12:55:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 2C7FC6DE0A43 for ; Mon, 15 Jun 2020 12:55:39 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnaTrwkPFzsd for ; Mon, 15 Jun 2020 12:55:38 -0700 (PDT) Received: from mail-ej1-f65.google.com (mail-ej1-f65.google.com [209.85.218.65]) by arlo.cworth.org (Postfix) with ESMTPS id D496A6DE0A42 for ; Mon, 15 Jun 2020 12:55:37 -0700 (PDT) Received: by mail-ej1-f65.google.com with SMTP id y13so18798339eju.2 for ; Mon, 15 Jun 2020 12:55:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:subject:in-reply-to:references:date:message-id :mime-version; bh=/e/zhBgHv2Uf/zDdEUuRJT07b+AUYMNLc+0Tw85uR6Q=; b=dBbIBnrZFyF8PO3GzLgtDMH2btnO2jMtb//3nUFvZdD/ibSIEGJlSKghAXIuZwZecN pop82xIEuHESlFw9zz+kkgFEuEwFrlXIMFEuBIDlb6t6dzedCT9cNw8cFaK7qE9A7C60 K5lArEp6Yogugs4k81wNc9jWOln1n7iH0j9hZaoeZ0bELAFR25ywkf8lU5qbsHS580Cn rjtyDnGsNBI8LplgDkovMxYBoAJoU+Xv6MIxhNF6cQIj+0+DAfQ9opoy6eQgDSQ/rinV PiOr5aRIBOt+7Gr0Aq2607Aqfg+PvYfDi5F90niOmljSfx+x6lqMfTwJCSmbAiKIuw5y Xfzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:subject:in-reply-to:references :date:message-id:mime-version; bh=/e/zhBgHv2Uf/zDdEUuRJT07b+AUYMNLc+0Tw85uR6Q=; b=PhHRs4ibo8sghabSLsxlHDttwnW1zhnego7u9oyRo3TlW2Nre1+rROUv76/NQo2i8Z VXn3DsIa5yrtrYqPzETKhL0+WQX0rKlvQ0OtGsMI0hfckA+VJO4jU+XJFVD/sq7d3Aop tdR0ZN6tyilxcURgLmXhOGy2UQPsLvWswWYYbPnwDf2SGPwZQsYLgdzE1T9tHciQjOvZ qWV73O7Jvkhf1BnpEfGESH1vq0gPSpXOKokgJchVpsxjQDrjidJ2yHR4hGa3hpGW2ZDu bQnfjrqlSSp6dhEIdNcPEhkTN05ccnVDF8yboy15cnO/175M7twCS1+q33U4EQKLe9Ez nIOw== X-Gm-Message-State: AOAM530sCXsxuM6He/f0jujIyyUZurTgYRgR27fsiGWq5bNN7bgtokO1 PW6Ll+nuMs0gsOjlFVhlL1BWlxc6 X-Google-Smtp-Source: ABdhPJynTuJeMfR5d7F5pdoBLODaPgFjzhT7ZmNOkOYgebVcRvl61WUOhAYRFZpYSk+7cY29YGfQeg== X-Received: by 2002:a17:906:4ec1:: with SMTP id i1mr26322393ejv.152.1592250936492; Mon, 15 Jun 2020 12:55:36 -0700 (PDT) Received: from powell.devork.be (2a02-8388-8480-1180-4c18-fc69-8d8c-22b5.cable.dynamic.v6.surfer.at. [2a02:8388:8480:1180:4c18:fc69:8d8c:22b5]) by smtp.gmail.com with ESMTPSA id fi13sm9715529ejb.34.2020.06.15.12.55.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 Jun 2020 12:55:35 -0700 (PDT) Received: (nullmailer pid 203501 invoked by uid 1000); Mon, 15 Jun 2020 19:55:34 -0000 From: Floris Bruynooghe To: David Bremner , notmuch@notmuchmail.org Subject: Re: [PATCH] Support aborting the atomic context In-Reply-To: <87a714y5uz.fsf@tethera.net> References: <20200614152319.57064-1-flub@devork.be> <87a714y5uz.fsf@tethera.net> Date: Mon, 15 Jun 2020 21:55:34 +0200 Message-ID: <871rmg14uh.fsf@powell.devork.be> MIME-Version: 1.0 X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: notmuch-bounces@notmuchmail.org Sender: "notmuch" X-Scanner: scn0 Authentication-Results: aspmx1.migadu.com; dkim=fail (body hash did not verify) header.d=gmail.com header.s=20161025 header.b=dBbIBnrZ; dmarc=none; spf=pass (aspmx1.migadu.com: domain of notmuch-bounces@notmuchmail.org designates 50.126.95.6 as permitted sender) smtp.mailfrom=notmuch-bounces@notmuchmail.org X-Spam-Score: 1.49 X-TUID: OHNKJY2MqT1g On Mon 15 Jun 2020 at 07:35 -0300, David Bremner wrote: > Floris Bruynooghe writes: > >> This is an implementation of what was suggested in >> id:87v9k96xtl.fsf@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.