Re: pop3d and imap4d's locking behaviour

[Alain Magloire]

> > > 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_open(mbox)
> 
>   mailbox_get_locker(mbox, &lock);
> 
>   locker_lock(lock);
> 
>   mailbox_count(mbox, &max);
> 
>   for(msgno = 1; msgno <= max; msgno++)
>   {
>     mailbox_get_message(..)
>       ..
>   }
> 
>   locker_unlock(lock)
> 
>   mailbox_close();
> 

Yes, that will work.  But must of the time you do not care enough
if mail is being appended at the same time .. Just call the program
again.
Having locks have disavantages, what if you hit CTRL-C
in the middle of the loop or you receive a SIGHUP/TERM.
We'll have to uglify the code to handle interuptions for little gain.

IMHO, frm/messages etc ... does not have to be precise, they are
just snapshots, if they choke because the world have changed
undernearth .. that's ok.  However, it may be nice to have
an option to turn the behaviour on:

./frm --lockfile # or something


a question:
Should the mailbox maintain an internal state of the mailfile
say mtime and check before every operation that it is consistent
if not return an error(EBUSY/ECANCELED).


> 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?

For POP3, it is settle, the lock must be on the duration of the session.

For IMAP4, I would say if the server see that the mailbox changed it
should reparse and send the appropriate notifications via unsolicited
responses.  I think we do something similar in the imap4 code ..
in imap4_sync () being call after certain commands.

> > > 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...

8) Not sure ..LOCK_ON_READ is the right approach anyway.

> > 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".

Exactly!
The problem was: we could not overload cleanly/completely mailbox_t.
But the idea was to create this "cache" mailbox with different policy:

switch (cache->policy)
{
    case MU_CACHE_OFFLINE:
        /* Not implemented.  */
        break;

    case MU_CACHE_DISCONNECTED:
        /* Not implemented.  */
        break;

    case MU_CACHE_ONLINE: // ??? no caching?
        /* Not implemented.  */

    default:
}