Re: [Evolution-hackers] Proposed fix for bug 311512

[Jeffrey Stedfast <fejj novell com>]

On Thu, 2007-04-26 at 07:50 +0100, Karl Relton wrote:
> On Wed, 2007-04-25 at 09:48 -0400, Jeffrey Stedfast wrote:
> > I'm not sure I'd call it get_filter_thread() because it's not getting a
> > thread, all it is really doing is getting you a 'wait' id (and ugh, the
> > new session_thread_wait() just busy-waits?)
> > 
> > I think if this type of solution is really the "best" way of doing it,
> > then I think it'd be better to just have a CamelFolder function
> > (camel_folder_wait_filtering()? I dunno)that waits for the filtering
> > operation to finish rather than providing a higher level with a wait id
> > that it should never have to know or care about.
> > 
> 
> Agreed - if this is the 'best way', I'll redo the patch as you suggest.
> 
> > 
> > But better still would be to trap the "folder_changed" signal for
> > folders that are currently in the process of filtering (CamelFolder
> > already listens for this event in order to invoke the filtering iirc, so
> > just stop the signal from propagating) and re-emit it later when
> > filtering is complete (obviously with the updated changes).
> > 
> 
> Yes - I had thought of this too.
> 
> The trouble is with the current code its not quite so simple AFAIK. The
> filtering that takes place is actually launched from the
> folder_changed() function in camel-folder.c. In other words, it is
> launched from the folder_changed event handler itself. Now I may be
> wrong here, but my assumption is that both evo and e-d-s register event
> handlers on this type of event - so that when such an event occurs code
> in both evo and e-d-s is executed ... perhaps even in parallel (in their
> own threads)?

not completely correct... 

when you trigger an event on a CamelObject, it first fires the "prep"
callback, which is what camel-folder.c:folder_changed() is (note that it
returns bool)

A prep event handler is the first handler called (event handlers are
fired sequentially, in order of connection - /not/ in parallel) and gets
to decide if the event propagates by returning TRUE (or FALSE if it
should be blocked - that's how freeze/thaw works).

> 
> If this is the case, then it is effectively too late to 'trap' the
> event, because evo will already be processing it.

all the event handler has to do is return FALSE to block other event
handlers from firing :)

>  Thus (AFAICS) even if
> camel is in a 'freeze' for folder_changed events, evo will still be
> firing on every folder_changed occurence.

only if folder_changed() returns TRUE - folder_changed() is what checks
if the folder is in a freeze state, and if it is blocks further events
from firing (by returning FALSE).

You have da powah!

> 
> One way to solve that would be to change things so that evo only fires
> when camel folder_changed stuff has really done: effectively at the end
> of a freeze AND filtering. That could be done by introducing a new event
> and making evo trigger off that perhaps?

unnecessary. all the tools are already available :)

> 
> 
> > That would be a much cleaner way of doing it.
> > 
> > Jeff
> 

Jeff