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

List:       kmail-devel
Subject:    Re: ClientInterface
From:       Don Sanders <sanders () kde ! org>
Date:       2003-07-21 2:56:20
[Download RAW message or body]

On Sunday 20 July 2003 23:29, Ingo Klöcker wrote:
> On Sunday 20 July 2003 13:36, don@sanders.org wrote:
...
> > > Remember that the typical use case is to have very few (about
> > > half a dozen max) clients, most of which are probably not even
> > > interested in all accounts and all folders. If we require
> > > maildir for concurrent KMail instances to work (which shouldn't
> > > be a problem), then we don't have any locking issues with the
> > > mails itself. Which leaves the index files, for which I don't
> > > see why locking shouldn't work effectively enough.
> >
> > 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?

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

> > > After all, for the
> > > common case and except for the system
> > > folders, the chance that two instances want to access the
> > > same folder at the same time is negligible. In case of
> > > collisions and for the system folders, simply making
> > > instance-private copies of the index files is probably the
> > > simplest method.
> >
> > I'm concerned with modification of a folder that is opened by
> > multiple clients. Consider two clients with the same folder open,
> > and outstanding deletes pending for that folder in both clients.
> > Then when one client writes the index the other client will now
> > have an out of date version of the index for that folder. So all
> > the KMMsgBase objects will have invalid offsets into the index of
> > their parent KMFolder. That's a problem.
> >
> > Maybe you could solve it by having each client make a private
> > copy of the file data for any folder  that is opened, keep a
> > record of what changes are made - disconnected imap style, and
> > when the folder is closed merged those changes into the original
> > folder. But I think that's a lot of unnecessary expense and
> > fragility, and would prefer to avoid it. Especially as I'm trying
> > to efficiently support search folders for global searches where
> > many folders can be opened simultaneously.
> >
> > There are other problems also. Currently we do have model/view
> > for folders (never mind the controller they went out of fasion in
> > the 70's). When a folder is modified by one mainwindow then any
> > other mainwindows are updated to show those changes, whether they
> > be insertions, deletes or modifications. Now if one client has a
> > folder open and pending changes, and another client makes
> > repeated changes to the folder (like checking for mail) then how
> > is the first client going to update the view when changes are
> > 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.

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

But yes, it would work for non-NFS, and this is the kind of change 
required to keep KMail working without a server.

Don.
_______________________________________________
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]