Re: [evolution-patches] [calendar] fix for #60736

[Rodrigo Moya <rodrigo novell com>]

On Fri, 2004-07-23 at 12:00 +0800, Not Zed wrote:
> 
> Will this actually make any difference?
> 
> The backtrace doesn't show the idle handler being recursively called,
> which I presume can't happen anyway.  The idle handler will implictly
> be removed automagically when it returns FALSE.  So explictly removing
> it is redundant.
> 
there are calls in those idle handlers that could trigger some calls to
the idle handler again.

In fact, this patch is still wrong, because we are getting the
async_signal_idle_id called twice (I get a warning in the call to
g_source_remove about signal_idle_id not being > 0). So, it seems the
idle handler is in fact being called twice.

> If it is being called too often, perhaps the code should be checking
> if its already set an idle handler before setting the new one up?
> 
the idle handler is individual to each ECal instance, so it should
really be creating an idle handler per ECal instance.

> Maybe async_signal_idle_cb is being called before async_auth_idle_cb
> and freeing its memory?
> 
that shouldn't happen, although you might be right. But
async_auth_idle_cb is supposed to being called from within open_calendar
call in open_async, and then, once that call is completed, it installs
the idle handler for async_signal_idle_cb.

> That code seems over-complicated for what it does and prone to
> issues :-/
> 
yes, the problem is that both the auth and the signal callbacks need to
be run on the main thread, since they need to get the signals to the
client. Do you have any suggestion for making it less complicated?

cheers