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

List:       kmail-devel
Subject:    Re: PATCH: Asynchronous filtering
From:       Ingo =?iso-8859-1?q?Kl=F6cker?= <kloecker () kde ! org>
Date:       2003-10-27 20:26:47
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 27 October 2003 19:37, Marc Mutz wrote:
> On Sunday 26 October 2003 21:21, Andreas Gungl wrote:
> > On Sunday 26 October 2003 20:24, Marc Mutz wrote:
> > > I'm open to new arguments for using threads to do work that is
> > > not compute-intensive, but I believe those can be rebutted just
> > > as easily. :-)
> >
> > Hi Marc,
> >
> > you had the chance to implement a process-based asynchroneous
> > modell, did you?
>
> I have a solution for the signing case, yes. It involves hooking up
> gpgme to the QEventLoop and using the async gpgme interface. Let's
> wait how people will react on that. I guess the direct dependance on
> gpgme will make some people nervous, even if they know we can't do
> without for the S/MIME case anyway. :-)

The problem being that gpgme is still GPL licensed which would prevent a 
KDE abstraction of gpgme to be included in kdelibs. But we had this 
discussion before.

> > Given that ThreadWeaver works well, the implementation of "other
> > tasks, such as pgp signature verification, trust db rebuilding etc"
> > could be combined with a solution that one can select several
> > hundreds of mails and pipe them through the filters without
> > freezing the UI. Filtering could be done in parallel where messages
> > to be piped through an external process don't block other messages
> > which need only internal actions (like header rewriting).
>
> Repeat after me: "You don't need threads for that" :-)
>
> You use threads iff
> 1. The operation is parallelizable or, but not chunkable.

Filtering is perfectly parallelizable.

> and
> 2. The operation takes a relatively long time

You don't seem to be using spamassassin. Piping messages through 
spamassassin takes an immense amount of time.

> and
> 3. The operation is mostly CPU-bound, not IO-bound

It seems to be CPU-bound. At least my KMail is absolutely unusable while 
spamassassin scans a message.

> and
> 4. KIO-slaves can't do the work

A KIO-slave for "pipe through"? I don't think so. ;-)

> and
> 5. The operation doesn't need to communicate much

The "pipe through" filter action doesn't need to communicate at all 
except when it's finished.

BTW, 2-5 also apply to OpenPGP operations. 1 also applies in case a 
message (e.g. a digest) consists of multiple signed text blocks/
messages.

> If the operation is chunkable, you can use a QTimer-approach.
> If the operation doesn't take a long time, then by definition it's
> non-blocking already.
> If the operation is not CPU-bound, it can be made non-blocking by
> using async IO.
> If the operation is IO-bound, threading will likely thrash the
> system. If KIO-slaves can do the work, it's by definition
> non-blocking. If the operation needs to communicate too much, locking
> can slow down the overall performance, as well as making the GUI
> thread less responsive than you hoped for.

Regards,
Ingo

[Attachment #5 (application/pgp-signature)]

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