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