Bug 62849

Summary: kmail freezes if filter-triggered process takes forever
Product: [Unmaintained] kmail Reporter: A T Somers <andre>
Component: filteringAssignee: kdepim bugs <kdepim-bugs>
Status: RESOLVED FIXED    
Severity: normal    
Priority: NOR    
Version: 1.5.3   
Target Milestone: ---   
Platform: openSUSE   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description A T Somers 2003-08-17 22:55:49 UTC 
Version:           1.5.3 (using KDE 3.1.3)
Installed from:    SuSE
Compiler:          gcc version 2.95.3 20010315 (SuSE)
OS:          Linux (i686) release 2.4.18-4GB

I am using a filteraction on to trigger a sound from kmail on the reception email that fits a certain criteria. That works ok. Basicly, it is triggered if no other filter matches, as the last filter in the list. I use the execute command action to execute this command:
play /home/andre/.kde/share/sounds/ogg/New_Mail_Notification.ogg

Now, if I am playing a MP3 using XMMS, I run into a problem. XMMS seems to block arts, which seems to block the play command, which lockes KMail. So basicly, if I am running XMMS and a new message arrives that triggers a sound, KMail freezes. It is debatable where this error is located. Would it be possible for KMail to just trigger the action and not look back at the result? After all, KMail doesn't need te result (unlike with the pipe through action). In general, I think that the interface should not be frozen solid because some filterprocess is taking it's time. 

BTW: thanks for a great mailclient!
Comment 1 Ingo Klöcker 2003-08-18 00:54:30 UTC 

*** This bug has been marked as a duplicate of 41514 ***
Comment 2 Ingo Klöcker 2003-08-18 23:19:29 UTC 
Oops, this isn't really a dupe of #41514. 
 
Yes, in theory we don't have to wait for the command to finish and we probably shouldn't. But 
this could lead to hundreds of commands started in quick succession without waiting for the 
others to end. Is this really a good idea?
Comment 3 A T Somers 2003-08-18 23:37:10 UTC 
Subject: Re:  kmail freezes if filter-triggered process takes forever

>Yes, in theory we don't have to wait for the command to finish and we
> probably shouldn't. But this could lead to hundreds of commands started in
> quick succession without waiting for the others to end. Is this really a
> good idea?
True, but... I am wondering if freezing KMail is better alternative? I think 
it is not. People who execute commands on a filter should know what they are 
doing ;-)
OTOH: Might I propose a feature here? It would be cool if I could have a 
filter _scedule_ a command, and have that command executed as soon as the 
action that triggered the sceduling has finished. To take my mail-sound again 
as an example. I could have the filter scedule to play my sound. The command 
would be put in a queue if the same command is not allready in the queue. As 
soon as the mailfetching that triggered the filters in the first place is 
ready, the commands in the queue would be executed. This would allow me to 
play a sound on the arrival of email that matches certain criteria, but would 
only sound it once, even if multiple matching emails would arrive. If I were 
to attach another sound to another class of messages, and such a message 
would arrive too, the sounds would both be played, because the commandline 
differs. 
This could also possibly avoid the problem you sketch above.

Andr
Comment 4 Ingo Klöcker 2003-08-19 00:22:46 UTC 
Subject: Re:  kmail freezes if filter-triggered process takes forever

This command scheduling sounds like a good idea. Please file a new 
wishlist item for this unless you think that this scheduling is exactly 
what is needed to fix the freezing problem.
Comment 5 A T Somers 2003-08-19 09:15:50 UTC 
Subject: Re:  kmail freezes if filter-triggered process takes forever

I don't think it would completely solve the problem (not if these sceduled 
processes would be waited for to complete too, at least). So, I entered a 
wishlist. It can be found as bug 62942.

Andr
Comment 6 Andreas Gungl 2004-05-24 21:16:08 UTC 
Fixed in CVS resp. KDE PIM 3.3 (by Ingo).