[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:58:21
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 27 October 2003 20:16, Marc Mutz wrote:
> On Sunday 26 October 2003 21:27, Till Adam wrote:
> > On Sunday 26 October 2003 20:24, Marc Mutz wrote:
> > The idea is to get a bunch
> > of messages and hand them off to the filtering subsystem as quickly
> > as possible to be able to give back control to the user sooner. The
> > overall time spent filtering is of secondary concern if the user
> > can continue working while it happens. Or so the theory.
>
> I do understand the goal of the changes, of course. I just don't want
> threading introduced into KMail except for those very special cases
> like compaction, provided the complexity payed in locking issues is
> well worth it. Consider for a moment the result of a compator thread
> locking a folder and the user clikcing on that folder. With simple
> QMutex-protection, the GUI-thread will _block_, waiting for the
> compactor to release the lock.

KMail won't allow the user to select a folder that's being compacted. 
And folder locking will anyway have to be implemented for mbox folders 
regardless of the usage of threads or not.

> > > > - we want to encapsulate other tasks, such as pgp
> > > > signature verification, trust db rebuilding etc into weaver
> > > > jobs as well
> > >
> > > Do we? You know, starting child processes (and gpg and the
> > > pipe-through commands _are_ and ever will be child processes) on
> > > a multiprocessing OS like Unix in _threads_ to avoid blocking
> > > makes so unbelievably no sense that it is rediculous. What could
> > > _possibly_ be the benefit of using threads if we use them only to
> > > fork off child processes? Hello? select()? QEventLoop?
> > > QSocketNotifier? KProcIO?
> >
> > Be my guest. :) No one has implemented the solutions you propose,
> > although they are of course perfectly doable. The weaver is a very
> > straight forward way to encapsulate tasks that would otherwise
> > block the gui and be notified when they are done. It might not be
> > the most efficient way to do it, but it's simple and works. It
> > abstracts away a lot of the unpleasantness of dealing with
> > asyncronous jobs. Feel free to provide us and the rest of kde with
> > a similarly straight forward implementation of that using
> > processes.
>
> Come on, you don't want to sell me threads as being easier than
> KProcess, now do you? If that's true for you, you most likely forgot
> the locking issues. "Works for me" doesn't count anymore when doing
> MT. You can't really test MT programs. They just fail when the other
> CPU skips a cycle and that will never be reproducable again :-(
>
> I know you know all this, but I wonder why you ignore it?

And I wonder why you don't implement a better solution for the "pipe 
through" case. The "pipe through" filter action was the cause for the 
most annoying blocking operation in KMail. If you present a better 
solution we'll dump the current approach in no time. But until then the 
current solution is 1000 times better than what we had before. Stop 
talking! Start hacking! A patch says more than a thousand words!

> > Threads are not the be
> > all and end all of software design. But they are a valuable tool. A
> > blunt axe, maybe, but it gets the fucking wood cut, if you catch my
> > drift ;).
>
> Yes, except that it's not about cutting wood, but more about peeling
> oranges. Of course, you _can_ use an ax for that, but who does? I'd
> rather take a sharp knive. :-)

"knive"? Does the spellchecker not work for you? ;-)

Anyway, so far KMail used a mace (a blocking KProcess call) for peeling 
oranges. It worked but it really sucked. If it would have had a sharp 
knife nobody would have complained.

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]