Patchworkβ Add shell script notmuch-retry

login
register
about
Submitter James Vasile
Date 2010-02-26 12:53:29
Message ID <87pr3sw43a.fsf@hackervisions.org>
Download mbox | patch
Permalink /patch/394/
State New
Headers show

Comments

James Vasile - 2010-02-26 12:53:29
It occurs to me that having generic ability to tell notmuch to retry
until the DB isn't locked might useful.  So I put the functionality in a
script that can sit between notmuch and various clients.  It will
simplify my emacs setup, and improve it since emacs's handling of
asynchronous processes isn't great.

This script calls notmuch and passes on all commandline arguments.  If
DB is locked, keep trying notmuch until the DB isn't locked.  Notmuch's
stdout and stderr go to stdout and stderr.  Returns notmuch's return
code.

Maybe this retry loop should be put in notmuch itself?

---
 notmuch-retry |   51 +++++++++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 51 insertions(+), 0 deletions(-)
 create mode 100755 notmuch-retry
Carl Worth - 2010-02-26 19:55:19
On Fri, 26 Feb 2010 07:53:29 -0500, James Vasile <james@hackervisions.org> wrote:
> Maybe this retry loop should be put in notmuch itself?

Perhaps it should. I've even imagined something that would queue a
request into a daemon if the database isn't currently available.

But of course there are issues about whether the caller would want to
know about the locking error, (or might actually need to block until the
operation is complete). So I'm not sure about the right answer here.

-Carl
James Vasile - 2010-02-27 04:10:16
On Fri, 26 Feb 2010 11:55:19 -0800, Carl Worth <cworth@cworth.org> wrote:
> On Fri, 26 Feb 2010 07:53:29 -0500, James Vasile <james@hackervisions.org> wrote:
> > Maybe this retry loop should be put in notmuch itself?
> 
> Perhaps it should. I've even imagined something that would queue a
> request into a daemon if the database isn't currently available.
> 
> But of course there are issues about whether the caller would want to
> know about the locking error, (or might actually need to block until the
> operation is complete). So I'm not sure about the right answer here.

--block and/or --queue?

Patch

diff --git a/notmuch-retry b/notmuch-retry
new file mode 100755
index 0000000..2d7fcbc
--- /dev/null
+++ b/notmuch-retry
@@ -0,0 +1,51 @@ 
+#!/bin/bash
+#
+# notmuch-retry --- call notmuch and retry if DB is locked
+#
+# Calls notmuch and passes on all commandline arguments.  If DB is
+# locked, keep trying notmuch until the DB isn't locked.  Notmuch's
+# stdout and stderr go to stdout and stderr.  Returns notmuch's return
+# code.
+#
+# Copyright 2010 James Vasile
+#
+# This is free software: you can redistribute it and/or modify it
+# under the terms of the GNU General Public License as published by
+# the Free Software Foundation, either version 3 of the License, or
+# (at your option) any later version.
+#
+# This software is distributed in the hope that it will be useful, but
+# WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+# General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this software.  If not, see
+# <http://www.gnu.org/licenses/>.
+#
+# Authors: James Vasile <james@hackervisions.org>
+
+bin=`which notmuch`
+
+notmuch_retry () {    
+    regex="already locked"
+    while [ 1 -gt 0 ]; do
+	$bin $@ 2>$err
+	retcode=$?
+	result=$(<$err)
+	if [[ $result =~ $regex ]]; then
+	    sleep 2.5
+	else
+	    if [ -n "$result" ]; then
+		echo $result >&2
+	    fi
+	    return $retcode
+	fi
+    done
+}
+
+err=$(mktemp)
+notmuch_retry $@
+retcode=$?
+rm $err
+exit $retcode