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

[Karl Relton <karllinuxtest relton ntlworld com>]

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)?

If this is the case, then it is effectively too late to 'trap' the
event, because evo will already be processing it. Thus (AFAICS) even if
camel is in a 'freeze' for folder_changed events, evo will still be
firing on every folder_changed occurence.

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?


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

Let me know if I am write or wrong on the event stuff, and which
direction you would suggest. I'm working elsewhere right at the moment,
but would be happy to return to this in due course to improve it
further.

Karl