Re: pop3d and imap4d's locking behaviour

[Sam Roberts]

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.

Sam

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!)