[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kmail-devel
Subject:    Re: ClientInterface
From:       Ingo =?iso-8859-1?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2003-07-21 23:27:58
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 21 July 2003 05:10, Don Sanders wrote:
> On Sunday 20 July 2003 23:29, Ingo Klöcker wrote:
> > On Sunday 20 July 2003 13:36, don@sanders.org wrote:
> > > The problem is KMail can't handle foreign processes modifying
> > > it's index files, especially while KMail is running and the
> > > folder for that index file is opened. It's equivalent to having a
> > > foreign process corrupt memory in the KMail process.
> >
> > No. It's not. If the index files are locked then at any time only
> > one KMail can modify them. Of course the index file must not be
> > locked the whole time a certain folder is visible but only if the
> > index file is accessed.
>
> It is a problem. Currently we hold open an index file while a folder
> is opened. E.g. I have a mainwindow showing my kmail folder currently
> and it will remain open as long as I'm looking at that folder. With
> the current KMail architecture we would have to lock the index file
> for as long as the KMFolder is open, as while the KMFolder is opened
> their exist KMMsgInfo objects that point into the index file and
> perform read/writes into the index file.
>
> If the index file is modified while those KMMsgInfo objects exist
> then those objects may end up pointing to bogus file offsets and
> consequently end up corrupting the index.
>
> Are you suggesting we redesign KMail so that it does not keep folders
> open? And change KMail so that every time an action is performed on a
> message KMail opens a folder reads in the index, performs the action,
> then closes the index and folder?

Yes, something like that. Of course the index should only be reread if 
the index file was changed by someone else. But the index file would 
have to be written each time something has been changed. And keeping 
the folder open is really only a problem with mbox. With maildir this 
problem doesn't exist. With mbox we could still keep the file open in 
read-only mode. Since we don't write any status information back to the 
folder files writing to mbox files is only necessary under two 
circumstances:
a) When a message is added.
b) When the folder is compacted.

And the only problematic action is the compaction.

> > > Also, to be honest I would prefer to avoid a maildir only
> > > limitation also.
> >
> > Why?
>
> Because it's an unnecessary limitation that is not jusitified.

That's your opinion.

> > > made by the second client? Poll the index file, and completely
> > > reparse it whenever changes are made?
> >
> > Exactly. You know that KDE provides easy-to-use classes for
> > watching files, right?
>
> It's not watching the files that is the main problem. The problem is
> retaining the integrity of objects that point into files which can be
> changed by other processes.

Nobody said it would be easy. But it's definitely far from being 
impossible. And, I have to repeat myself, this is only a problem for 
people who use multiple instances of KMail at the same time. They will 
have to live with a reduced performance.

> > > Another problem is serial numbers, if there are multiple clients
> > > each with their own serial numbers then duplicate serial numbers
> > > are going to be assigned.
> >
> > This could be avoided by writing the next possible serial number to
> > a file or, probably even better, by simply touching a file called
> > 12345 in ~/.kde/share/apps/kmail/serialnumbers/ where 12345 is the
> > next available serial number. Each time a new serial number is
> > needed KMail would look for this file, probably use a locking
> > method to avoid a race condition, and then write/touch a new file.
> > Of course this would be slower than a memory only solution. But at
> > least it shows that the serial number problem is solvable. And it
> > does even work for several KMails which run on different machines
> > accessing the same home directory via NFS which the client/daemon
> > solution can't solve.
>
> I'm under the impression that NFS clients cache the list of files in
> directories. In which case this doesn't solve the problem for NFS.

The NFS clients should be notified by the server in case the list of 
files changes. Whether this really happens is unfortunately more than 
questionable. All the problems that we have with NFS mounted ~/Mail 
directories show that NFS doesn't really work as advertised. And that's 
probably the real showstopper.

Regards,
Ingo


[Attachment #5 (application/pgp-signature)]

_______________________________________________
KMail Developers mailing list
kmail@mail.kde.org
http://mail.kde.org/mailman/listinfo/kmail


[prev in list] [next in list] [prev in thread] [next in thread]