1 Return-Path: <amdragon@gmail.com>
\r
2 X-Original-To: notmuch@notmuchmail.org
\r
3 Delivered-To: notmuch@notmuchmail.org
\r
4 Received: from localhost (localhost [127.0.0.1])
\r
5 by olra.theworths.org (Postfix) with ESMTP id 44756431FB6
\r
6 for <notmuch@notmuchmail.org>; Fri, 28 Jan 2011 08:57:36 -0800 (PST)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5
\r
12 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001,
\r
13 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled
\r
14 Received: from olra.theworths.org ([127.0.0.1])
\r
15 by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)
\r
16 with ESMTP id bgIXxWvtIhxM for <notmuch@notmuchmail.org>;
\r
17 Fri, 28 Jan 2011 08:57:35 -0800 (PST)
\r
18 Received: from mail-qw0-f53.google.com (mail-qw0-f53.google.com
\r
19 [209.85.216.53]) (using TLSv1 with cipher RC4-MD5 (128/128 bits))
\r
20 (No client certificate requested)
\r
21 by olra.theworths.org (Postfix) with ESMTPS id 83BCE431FB5
\r
22 for <notmuch@notmuchmail.org>; Fri, 28 Jan 2011 08:57:35 -0800 (PST)
\r
23 Received: by qwe5 with SMTP id 5so3713284qwe.26
\r
24 for <notmuch@notmuchmail.org>; Fri, 28 Jan 2011 08:57:35 -0800 (PST)
\r
25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
\r
26 h=domainkey-signature:mime-version:sender:in-reply-to:references:date
\r
27 :x-google-sender-auth:message-id:subject:from:to:cc:content-type;
\r
28 bh=R1ggX/9a5PmlB/yJsW5F1VF6tPCFQ1ua3ffXNhHt8FI=;
\r
29 b=rg3ZTAYBesEUlaDGitSPir0WKIo9v/caYmPZQEJav3LClj0rbgLZh9gQSIfRr/LkOc
\r
30 XMN8KbKk4uzkw0rMCr1p/PJaSEaHXfQJV09EpdhRnMgD4ZLPUW5VGmSgJuPDhAHTo9O+
\r
31 8oouAzsji+NYYguqwIoVkIKOb3XO9UrvP4usc=
\r
32 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
\r
33 h=mime-version:sender:in-reply-to:references:date
\r
34 :x-google-sender-auth:message-id:subject:from:to:cc:content-type;
\r
35 b=cWbR38hGEJRQht2MSUVqidMBfm65IszE/5UWX5qYV8Fqk2y9UYjRSFNQsh97QIq9Yh
\r
36 bNuCemK6QbvoZDqjYtr/N95UYed71bQ+yFHdwsBz1H/o6o/29WBg/ioZUSeBZJA7xqju
\r
37 JNMLAfomJ+kN2tTmf40g9RGTZch2g4yENRokU=
\r
39 Received: by 10.229.238.148 with SMTP id ks20mr2910814qcb.78.1296233854560;
\r
40 Fri, 28 Jan 2011 08:57:34 -0800 (PST)
\r
41 Sender: amdragon@gmail.com
\r
42 Received: by 10.229.97.143 with HTTP; Fri, 28 Jan 2011 08:57:34 -0800 (PST)
\r
43 In-Reply-To: <1296228975-ner-3626@everglades>
\r
44 References: <87fwsetdin.fsf@kepler.schwinge.homeip.net>
\r
45 <8762taxk9y.fsf@algae.riseup.net>
\r
46 <87vd1a84qj.fsf@servo.finestructure.net>
\r
47 <AANLkTi=pPgcPXUN_XTXa0gAkbTR_OF4XxCP-d4-Be2pt@mail.gmail.com>
\r
48 <87fwsdobpy.fsf@yoom.home.cworth.org>
\r
49 <877hdps6og.fsf@kepler.schwinge.homeip.net>
\r
50 <1296228975-ner-3626@everglades>
\r
51 Date: Fri, 28 Jan 2011 11:57:34 -0500
\r
52 X-Google-Sender-Auth: ExmzuTiUvxJ-Ao0dU5RJdBCpL2o
\r
53 Message-ID: <AANLkTim9FEEn6bpeAb1oHVScs4RGbK-UrFY+52ZKWv4E@mail.gmail.com>
\r
54 Subject: Re: notmuch's idea of concurrency / failing an invocation
\r
55 From: Austin Clements <amdragon@mit.edu>
\r
56 To: Mike Kelly <pioto@pioto.org>
\r
57 Content-Type: multipart/alternative; boundary=00163646b8ee726b67049aeaf657
\r
58 Cc: notmuch@notmuchmail.org
\r
59 X-BeenThere: notmuch@notmuchmail.org
\r
60 X-Mailman-Version: 2.1.13
\r
62 List-Id: "Use and development of the notmuch mail system."
\r
63 <notmuch.notmuchmail.org>
\r
64 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
65 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
66 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
67 List-Post: <mailto:notmuch@notmuchmail.org>
\r
68 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
69 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
70 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
71 X-List-Received-Date: Fri, 28 Jan 2011 16:57:36 -0000
\r
73 --00163646b8ee726b67049aeaf657
\r
74 Content-Type: text/plain; charset=ISO-8859-1
\r
76 On Fri, Jan 28, 2011 at 10:36 AM, Mike Kelly <pioto@pioto.org> wrote:
\r
78 > On Fri, 28 Jan 2011 10:45:19 +0100, Thomas Schwinge <thomas@schwinge.name>
\r
80 > > > It would definitely be nice to avoid the complexity inherent in having
\r
82 > > > daemon, but how do you imagine "queue on a lock" to work? We don't have
\r
83 > > > anything like that in place now.
\r
85 > > I suppose what he means is trying to get the lock, and if that fails wait
\r
86 > > a bit / wait until it is available again.
\r
88 > > Actually, as a next step, wouldn't it also be possible to add some
\r
89 > > heuristic to avoid ``notmuch new'' (being a low-priority task) blocking
\r
90 > > some interactive user (UI; high-priority task)? But we can pursue such
\r
91 > > schemes as soon as the basic infrastructure is in place.
\r
93 > Couldn't we pretty much get the desired behavior by using flock(2)?
\r
94 > Basically, take out a LOCK_EX when we need to write, and a LOCK_SH when
\r
95 > we only need to read. Using the blocking form, things should pretty much
\r
96 > just queue up and take their turn, right?
\r
98 > I'm not familiar with Xapian, but if it doesn't give us something we
\r
99 > could use this sort of locking on, couldn't we just add some
\r
100 > /path/to/mail/.notmuch.lock file that we open to hold a lock on?
\r
103 Yes, exactly. All of this. Unfortunately, Xapian doesn't expose the
\r
104 ability to block on the lock (see the fcntl call in backends/flint_lock.cc,
\r
105 which is hard-coded to the non-blocking F_SETLK instead of F_SETLKW), so
\r
106 we'd either need a new Xapian option, or we would just have to wrap our own
\r
107 flock/fcntl lock around things as you suggest.
\r
109 --00163646b8ee726b67049aeaf657
\r
110 Content-Type: text/html; charset=ISO-8859-1
\r
111 Content-Transfer-Encoding: quoted-printable
\r
113 <div class=3D"gmail_quote">On Fri, Jan 28, 2011 at 10:36 AM, Mike Kelly <sp=
\r
114 an dir=3D"ltr"><<a href=3D"mailto:pioto@pioto.org">pioto@pioto.org</a>&g=
\r
115 t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
\r
116 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
\r
117 <div class=3D"im">On Fri, 28 Jan 2011 10:45:19 +0100, Thomas Schwinge <<=
\r
118 a href=3D"mailto:thomas@schwinge.name">thomas@schwinge.name</a>> wrote:<=
\r
120 > > It would definitely be nice to avoid the complexity inherent in h=
\r
122 > > daemon, but how do you imagine "queue on a lock" to wor=
\r
123 k? We don't have<br>
\r
124 > > anything like that in place now.<br>
\r
126 > I suppose what he means is trying to get the lock, and if that fails w=
\r
128 > a bit / wait until it is available again.<br>
\r
130 > Actually, as a next step, wouldn't it also be possible to add some=
\r
132 > heuristic to avoid ``notmuch new'' (being a low-priority task)=
\r
134 > some interactive user (UI; high-priority task)? =A0But we can pursue s=
\r
136 > schemes as soon as the basic infrastructure is in place.<br>
\r
138 </div>Couldn't we pretty much get the desired behavior by using flock(2=
\r
140 Basically, take out a LOCK_EX when we need to write, and a LOCK_SH when<br>
\r
141 we only need to read. Using the blocking form, things should pretty much<br=
\r
143 just queue up and take their turn, right?<br>
\r
145 I'm not familiar with Xapian, but if it doesn't give us something w=
\r
147 could use this sort of locking on, couldn't we just add some<br>
\r
148 /path/to/mail/.notmuch.lock file that we open to hold a lock on?<br></block=
\r
149 quote><div><br></div><div>Yes, exactly. =A0All of this. =A0Unfortunately, X=
\r
150 apian doesn't expose the ability to block on the lock (see the fcntl ca=
\r
151 ll in backends/flint_lock.cc, which is hard-coded to the non-blocking F_SET=
\r
152 LK instead of F_SETLKW), so we'd either need a new Xapian option, or we=
\r
153 would just have to wrap our own flock/fcntl lock around things as you sugg=
\r
155 <div><br></div></div>
\r
157 --00163646b8ee726b67049aeaf657--
\r