[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]