(*** This bug was imported into bugs.kde.org ***) Package: kmail Version: 1.4.3 (using KDE 3.0.3 ) Severity: wishlist Installed from: SuSE Compiler: gcc version 2.95.3 20010315 (SuSE) OS: Linux (i686) release 2.4.18 OS/Compiler notes: This one bugs me since I'm using KMail in combination with SpamAssassin: While a message is received the whole app freezes and you can't do anything. Sometimes the network checks are slow and receiving 100 messages takes more tahn 30 minutes for me and sometimes freezes my whole machine (including kicker panels etc.). (According to SA's timelogs doesn't it really take so long to process the message. Seems like there's some overhead somewhere else.) But that's because the filters aren't run async and I'm pretty shure there's already a bug/wish complaining about this. What I wanted to suggest is the following: Currently for each pipe process a bash is forked. Why don't you do it like Perl's exec() routine [1]; "[...] the argument is checked for shell metacharacters and if there are any the entire argument is passed to the system's command shell for parsing [...]. If there are no shell metacharacters in the argument it is split into words and passed directly to execvp which is more efficient." Sounds like a good idea doesn't it? :) Malte [1]http://www.perldoc.com/perl5.6/pod/func/exec.html (Submitted via bugs.kde.org) (Called from KBugReport dialog)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 19 August 2002 17:54 Malte S.Stretz wrote: <snip> > What I wanted to suggest is the following: Currently for each pipe > process a bash is forked. Why don't you do it like Perl's exec() > routine [1]; "[...] the argument is checked for shell metacharacters > and if there are any the entire argument is passed to the system's > command shell for parsing [...]. If there are no shell metacharacters > in the argument it is split into words and passed directly to > execvp which is more efficient." > > Sounds like a good idea doesn't it? :) <snip> I don't think that this makes such a difference really. Async filters are a nice idea maybe for KDE3.2... Marc - -- If free-software authors lose the right to disclaim all warranties and find themselves getting sued over the performance of the programs they've written they'll stop contributing free software to the world. -- Bruce Perens: Open Sources: Voices from the Open Source Revolution -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9YWAj3oWD+L2/6DgRAsf5AJ46x+Psd5H9cBDKPXdhBDFku/jmJQCgmQsR DB5t1BP/Cf0wUVG+m9DAab8= =KK37 -----END PGP SIGNATURE-----
On Monday 19 August 2002 23:16 CET Marc Mutz wrote: > On Monday 19 August 2002 17:54 Malte S.Stretz wrote: > <snip> > > What I wanted to suggest is the following: Currently for each pipe > > process a bash is forked. Why don't you do it like Perl's exec() > > routine [1]; "[...] the argument is checked for shell metacharacters > > and if there are any the entire argument is passed to the system's > > command shell for parsing [...]. If there are no shell metacharacters > > in the argument it is split into words and passed directly to > > execvp which is more efficient." > > > > Sounds like a good idea doesn't it? :) > <snip> > > I don't think that this makes such a difference really. I can't prove it but I think calling bash makes each call take the double time spamc needs alone. (You can configure it to log the time it needed to process a message.) (And the double memory. spamc is ~21kB big; it's made to be lightweight and fast.) That's probably not much but it adds up for many messages. Havy you ever tried to use SA with KMail? Try it. It's fun. Additionally there's the point that KMail sometimes freezes my whole KDE when it's piping. I already tried calling `nice -5 spamc` which didn't help. It might be worth a try at least (I'd provide a patch it if I spoke C++ good enough). Maybe for KDE3.2... :) > Async filters are a nice idea maybe for KDE3.2... Definitely. Malte
Bah, I did some testing and not starting a shell to execute commands isn't really worth it -- the rest is a dup of bug 41514. *** This bug has been marked as a duplicate of 41514 ***