From mboxrd@z Thu Jan 1 00:00:00 1970 From: Francisco J Ballesteros Content-Type: multipart/alternative; boundary="Apple-Mail=_B8F3F7B6-E507-4542-A0FF-0326BD207652" Message-Id: <1A70F044-4B17-4D0F-AE80-2BA28F0D28D1@lsub.org> Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Date: Thu, 18 Apr 2013 16:24:51 +0200 References: <7C2F640A-2A94-4AA1-9CE9-4E4845F0860F@lsub.org> <96ac8463d3e63c152de3bf159eb53fb6@kw.quanstro.net> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-Reply-To: <96ac8463d3e63c152de3bf159eb53fb6@kw.quanstro.net> Subject: Re: [9fans] upas locking Topicbox-Message-UUID: 4382b13e-ead8-11e9-9d60-3106f5b1d025 --Apple-Mail=_B8F3F7B6-E507-4542-A0FF-0326BD207652 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Yes, I noticed the comment, but I thought it was wrong. The problem was that we had quite a number of upas/fs's and scanmails running and it was because one of them had a problem and kept a /mail/tmp/L.mbox file locked. All other ones kept waiting for that (although all of them were using different "mboxes" created by the piped script at /mail/tmp/$pid.blah.blah Making this change made problems go away, and I didn't notice any problem in imap so far. I guess I'll have to reread the imap source to see if it really requires one lock per dir instead of one per mbox, but even so, I think imap should use a different lock for that, it's upas/fs the one I'm talking about. thanks for the hint On Apr 18, 2013, at 4:04 PM, erik quanstrom wrote: > i think the comment above the function is important > "we use one lock per directory". it's been a long time since > i worked on nupas, so i don't recall all the details, but > iirc, imap4d relies on having one lock per directory. --Apple-Mail=_B8F3F7B6-E507-4542-A0FF-0326BD207652 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Yes, = I noticed the comment, but I thought it was = wrong.

The problem was that we had quite a number of = upas/fs's and scanmails
running and it was because one of them = had a problem and kept a
/mail/tmp/L.mbox file locked. All = other ones kept waiting for that
(although all of them were = using different "mboxes" created by the
piped script at = /mail/tmp/$pid.blah.blah 

Making this = change made problems go away, and I didn't notice any
problem = in imap so far. I guess I'll have to reread the imap source to = see
if it really requires one lock per dir instead of one per = mbox, but even so,
I think imap should use a different lock = for that, it's upas/fs the one I'm
talking = about.

thanks for the = hint

On Apr 18, 2013, at 4:04 PM, erik quanstrom = <quanstro@quanstro.net>= wrote:


i worked on nupas, so i don't recall = all the details, but
iirc, imap4d relies on having = one lock per directory.