From kmail-devel Fri Mar 31 09:16:00 2000 From: Don Sanders Date: Fri, 31 Mar 2000 09:16:00 +0000 To: kmail-devel Subject: Re: Changes in KMail and *Warning* X-MARC-Message: https://marc.info/?l=kmail-devel&m=95449822418521 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.