From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 2E44E6DE00BD for ; Tue, 2 Aug 2016 15:22:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 tagged_above=-999 required=5 tests=[AWL=0.000, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled 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 Kv3Scf1rFszg for ; Tue, 2 Aug 2016 15:22:06 -0700 (PDT) Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197]) by arlo.cworth.org (Postfix) with ESMTPS id 2DA076DE00B8 for ; Tue, 2 Aug 2016 15:22:05 -0700 (PDT) Received: from remotemail by fethera.tethera.net with local (Exim 4.84_2) (envelope-from ) id 1bUi4p-0004G4-VJ; Tue, 02 Aug 2016 18:22:19 -0400 Received: (nullmailer pid 27041 invoked by uid 1000); Tue, 02 Aug 2016 22:21:58 -0000 From: David Bremner To: Matt Armstrong , notmuch@notmuchmail.org Subject: Re: A systematic way of handling Xapian lock errors? In-Reply-To: References: User-Agent: Notmuch/0.22.1+61~g2ce0f13 (https://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Wed, 03 Aug 2016 07:21:58 +0900 Message-ID: <87lh0evmk9.fsf@maritornes.cs.unb.ca> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Aug 2016 22:22:14 -0000 Matt Armstrong writes: > To address both, has something like this ever been considered: > > notmuch --lock_timeout COMMAND ARG... > > Then frontends like Emacs could lean on retry logic written in C. If > this seems workable, it is something I can try implementing. notmuch in git master uses xapians lock retry if present (xapian 1.3+). Currently there is no timeout, but Olly seemed receptive to the idea of adding one, so I'd suggest that's the right place to work on improving this. You may find that just having unbounded lock retries (i.e. blocking opens) is enough for your issues. d