[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pop3d and imap4d's locking behaviour

From: Sam Roberts
Subject: Re: pop3d and imap4d's locking behaviour
Date: Sun, 3 Mar 2002 20:55:38 -0500
User-agent: Mutt/1.3.16i

It seems to me that in theory, you should always lock a file
before reading it, otherwise you can read it while somebody
else is writing it. You should only do so as long as you need
to, of course.

Is it really that important of an optimization to not dotlock
a file? That's why I thought about the MU_LOCKER_NO_LOCK, then
if you truly don't care about the data (like messages), what the
hell, you can disable locking.


Quoting Alain Magloire <address@hidden>, who wrote:
> > Quoting Alain Magloire <address@hidden>, who wrote:
> > I'm thinking about adding a MU_LOCKER_NO_LOCK mode, which will
> > silently NOT lock the mailbox, so you can get that mode if you
> > want. This would allow utilities that are opening mailboxes read
> > only and just want to be fast (like "messages") to set this
> > as a flag.
> In theory it should not be necessary utils
> like messages/frm/from should open the mailbox readonly
> and never access write functions that could potentially locker_t
> But it would still be nice on the safe side to MU_LOCKER_NO_LOCK
> and maybe handy for something else.
> > Also, I want to add a MU_LOCKER_EXTERNAL flag (and a
> > locker_set_external(debug_t d, const char* program)) to call
> > dotlock (or mutt_dotlock, if you'd rather). I think this would
> > address the setgid irritation.
> Yep!  This was forever on my TODO list.
> > As soon as I can...
> Cool!
> > 
> > Sam
> > p.s. Spring is coming fast, a good thing.
> 8-) Ho! yes.

Sam Roberts <address@hidden> (Vivez sans temps mort!)

reply via email to

[Prev in Thread] Current Thread [Next in Thread]