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 _______________________________________________ Evolution-hackers mailing list [email protected] http://mail.gnome.org/mailman/listinfo/evolution-hackers
