[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pop3d and imap4d's locking behaviour
From: |
Alain Magloire |
Subject: |
Re: pop3d and imap4d's locking behaviour |
Date: |
Sun, 3 Mar 2002 21:49:12 -0500 (EST) |
>
> 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.
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.
> 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-) ?
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.
- pop3d and imap4d's locking behaviour, Sam Roberts, 2002/03/01
- Re: pop3d and imap4d's locking behaviour, Sam Roberts, 2002/03/01
- Re: pop3d and imap4d's locking behaviour, Sam Roberts, 2002/03/02
- Re: pop3d and imap4d's locking behaviour, Alain Magloire, 2002/03/02
- Re: pop3d and imap4d's locking behaviour, Sam Roberts, 2002/03/02
- Re: pop3d and imap4d's locking behaviour, Alain Magloire, 2002/03/02
- Message not available
- Re: pop3d and imap4d's locking behaviour, Sam Roberts, 2002/03/03
- Re: pop3d and imap4d's locking behaviour,
Alain Magloire <=
- Message not available
- Re: pop3d and imap4d's locking behaviour, Sam Roberts, 2002/03/04
- Re: pop3d and imap4d's locking behaviour, Alain Magloire, 2002/03/05