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

List:       kmail-devel
Subject:    Re: PATCH: Asynchronous filtering
From:       Marc Mutz <mutz () kde ! org>
Date:       2003-10-27 18:37:01
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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

> Unfortunatly others took the job while you didn't. There are 
> pro's and con's - but the approach isn't as bad as you describe it.

Of course, it works. But I hope you agree that introducing threads into 
a program that is not layered and not thread-aware is going to be more 
bugfixing work in the end than using good ol' KProcIO and timers. And 
please consider the overhead of a QMutex per KMMessage :-o

> 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.
and
2. The operation takes a relatively long time
and
3. The operation is mostly CPU-bound, not IO-bound
and
4. KIO-slaves can't do the work
and
5. The operation doesn't need to communicate much

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.

Have a look at a (background) search. That does _not_ use threads and 
you almost don't notice it (or didn't in 1.5.x) except when the IO load 
get so high that the kernel can't cope anymore. You can continue to 
read your mail, write new mail, you just can't start another search, 
but that would be quite easy to solve if need be.

Marc

-- 
It's good fortune for the government that the masses don't think.
                                                         -- Adolf Hitler

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