[prev in list] [next in list] [prev in thread] [next in thread]
List: kmail-devel
Subject: Re: Changes in KMail and *Warning*
From: Sven Radej <sven () lisa ! exp ! univie ! ac ! at>
Date: 2000-03-31 8:09:23
[Download RAW message or body]
On Fri, 31 Mar 2000, Don Sanders wrote:
>Excellent!
>
>Thanks Sven :-)
Thank you! :-)
Well, there are some problems still. I have an 2500 message folder. New KMail
compacts it (much) slower than old one. I donīt know why.
If kmail exits and keeps compacting it wonīt react on dcop-call from new kmail.
At home, I redesigned the exiting procedure and:
- compacting is now non-blocking *if* there is no windows - it calls
processEvents. This isnīt dangerous since there is noone else who could mess
with folders. If there is a window (or if window suddenly appears because of
dcop call) compacting, is blocking (or we can make it nonblocking if we
provide a modal progress dialog)
- You can dcop-call kmail at any time, up to the point when objects (sender,
account manager, folder manager and the like) get deleted it looks like this
KMKernel::cleanup()
{
o We are still registered with dcop, sending if any is finished. We can
be called via dcop at any time and abort exiting. The next steps are
atomic, dcop call can happen only between them:
- we compact if/what is needed. event loop runs, but stops
when/if window appears ->user has to wait till itīs finished.
- if there was no dcop call, we close(true) all folders (I think we need
this)
- if there was no dcop call, we write config for some objects
and addressbook.
o At this point we declare us in shutting-down-state. This is
the *start* of race interval - we are registered an can be called but we
wonīt do de job weīre asked to. Our dcop interface is instructed to
return -1 (=We are shutting down, wait a bit and do the job yourself)
The next steps are atomic, dcop call can happen only between them:
- delete objets (sender, managers, etc.). They may write to config
in their destructors.
- sync config.
o Unregister from dcop server. This is the *end* of race intervall. We donīt
hold folders or config any more, and at this point another kmail can start.
- delete old attachment dirs if any
- quit the application and exit.
}
A very good thing - if kmail dies it will be disconnected from dcop (this is no
some our handler, dcop server does it). So we wonīt see any calling of dead
kmails s we have seen in kde-1 (famous "server died while ready/busy")
This is the concept I have on my hard disk now. I didnīt commit it yet, since I
want to be sure that it works ok (plus some little fixes to add). I think it
doesnīt interfere (too much) with any future concept folder management or
message format.
There are some questions:
Unless I got it wrong, new kio-pop3 code is non blocking. So there is
possibility that a folder is used while it is filled with new message. Like
this: we are getting a loong e-mail and we start deleting some old message from
inbox. Or we start compacting folders (ok, compacting wonīt start if sender or
pop3 work. And only way to start pop3 or sender is by gui or timer - this
cannot happen during compacting since compacting blocks gui if there is gui).
Anyway, I think we should (or do we?) have some mutex in KMFolder.
--
Sven Radej radej@kde.org
KDE developer Visit http://www.kde.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic