[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: Mon, 4 Mar 2002 20:49:58 -0500
User-agent: Mutt/1.3.16i

Quoting Alain Magloire <address@hidden>, who wrote:
> > 
> > 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.
> You are getting in an area where flat mbox is a real disavantage/problem.


Of course, then you have to open/close each individual message, which
will slow down iterating through the messages. You win some and lose
some. :-(

> So when to lock? For an industrial strength program, you pretty much
> have to lock at __all__ operations.  Or be smarter, maintaining a mtime
> and throw an error when you are no longer consistent.  This can
> be very cumbersome for programming, especially simple readonly
> program like frm/messages/from etc ..
> > 
> > Is it really that important of an optimization to not dotlock
> > a file?
> For distributed systems (say NFS), many implementations
> have very effective read caching, but a simple write takes hours(Ok, maybe
> a few seconds) but still for lot of transactions you pay the price.
> An other example, my mailbox contains 2000 msgs(yes I know..)
> It would not be efficient to create/delete 2000 times the .lock file.

Ok, I see your point about relocking at every message while iterating
through and printing all the subjects. That sucks badly. But...
locking just once isn't so bad.

frm could do:


  mailbox_get_locker(mbox, &lock);


  mailbox_count(mbox, &max);

  for(msgno = 1; msgno <= max; msgno++)



In this case the mailbox would be locked only once, and remain
locked for the entire run through the mailbox, which will be
"bounded but indeterminate" time.

With servers the daemon could do something similar, but with a time
out. Basically, explicitly lock the mailbox on SELECT, then go
back to the command read/process loop. As long as the client
keeps asking to do things (list, download headers, etc.) then
keep the mailbox locked, then when the connection is quiet for
more than 30 seconds or so then explicity unlock the mailbox. It
will get locked again when they start doing things.

This kind of breaks interactive client use into sequences of command
activity through which the lock is maintained.

Does this seem at all useful?

> > 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.
> can it be an option MU_LOCKER_NO_LOCK_ON_READ 8-) ?

Ouf. Yes. But I took the flags off of locker_lock()... they
were cast to (void), and nothing but fcntl() distinguishes
between locking and dotlocking anyhow...

> Also note that elm uses a second approach: to copy the entire mbox
> in /tmp/MBOX.user or something and work with this version.
> Maybe we could provide the same:
> mailbox_cache(mailbox_t *, char * url_src, char *url_dst);
> mailbox_cache(&mbox, "/var/mail/alain", "/tmp/Mbox.alain"); 
> mailbox_cache would take care of maintaining the sync.
> It could be usefull for things like:
> mailbox_cache(&mbox, "pop3://address@hidden", "/home/alain/mail/pop3"); 
> This was to be for mailutils2, because there is currently no sync interface
> to deal with remote mailboxes like POP3 or IMAP4.

That could be cool, particularly if we could implement
imap4's "disconnected mode".


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

reply via email to

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