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

List:       kmail-devel
Subject:    Re: Changes in KMail and *Warning*
From:       Don Sanders <don () sanders ! org>
Date:       2000-03-31 9:16:00
[Download RAW message or body]

On Fri, 31 Mar 2000, Sven Radej wrote:
> 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.

How much slower is it? I didn't notice that.

> 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")

Okay I think I understand this. It seems okay, except for one point I mention
below.

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

Ok, I don't have any comments pending so feel free to commit it when your'e
ready. (but read my comment below first)

> There are some questions:
>  Unless I got it wrong, new kio-pop3 code is non blocking.

Yes that is correct.

> So there is
>  possibility that a folder is used while it is filled with new message

Yes, or the folder could even be deleted, or renamed or something.

> 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

I don't think we need any mutex in KMFolder.

Firstly realise that whenever KMail is 'idle' that is waiting to process
events, it is safe to do stuff with folders (like add messages etc). (I mean
KMail is basically waiting for the user to do this). If it's otherwise then
KMail has a bug. More specifically it's ok to call
KMAccount->processNewMsg(KMMessage*).

The new pop3 account downloads mails using a pop3 kioslave, it downloads them
into memory nothing is written to disk while a message is still being
downloaded. Once the message is fully downloaded the kioslave emits a QT
'result' signal. This signal won't be given off straight away, the signal
won't be emitted until KMail is idle and ready to process events (it wouldn't
hurt to check this with a KIO Slave expert though).

This means KMail could process the messages as soon as it receives the result
signal. Actually it only processes messages once every 2 seconds as if you have
a fast pop3 connect (like on a lan) it's annoying and CPU wasting to update the
QListView for every message downloaded (especially if you are downloading
hundreds of messages).

Either way KMail should only be processing new messages when it's safe.


Anyway try it out for yourself, create an experimental pop account (to be
safe check leave mail on server) and delete old mail as new mail arrives in a
folder. I spent a couple hours doing this just to make sure everything is ok.

> if there is gui).
So I am concerned if you plan to change things so that events will be
processed during compaction. As this could mess up processing of new messages.
This could happen even without the new background downloading of mail, there
could still be problems with the old pop account and interval mail checking (if
the interval mail checking fired off when there were 'no gui').

If you are going to do this you should make sure the all interval mail checking
timers are killed and no background mail checking is in progress while you are
compacting folders. You should be careful, you're breaking the it's safe to do
stuff with folders when KMail is idle and waiting to process events rule.

> Anyway, I think we should (or do we?) have some mutex in KMFolder.

No I don't think so.

I should note some concerns I have:

1) I changed the 'server' stuff in main.cpp. I allowed KMail to send and
receive mail at the same time, I modified the server so that an int was used
instead of a bool. IIRC entering check mail will increment the count once, and
sending mail also increments the count. When the count is positive
IPC communication isn't allowed. This could probably be improved on, you might
be able to disable IPC only when sending or processing messages or
something.

Anyway it would be good if you could check to make sure I haven't broken the
IPC stuff.

2) There is a bug in background mail checking if you quit when background
checking is in progress (or more forgiveable if KMail crashes) then the next
time the account is checked you will receive the same mails again.

3) If the pppd connection dies while checking mail the pop3 kioslave (maybe all
kioslaves) don't give off an error signal like they should. So the background
checking get stuck on, and you have to quit KMail to reset it. (Even pressing
the cancel button doesn't help). This seems to be a kioslave bug.

BFN,
Don.

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