Re: [Evolution-hackers] Issues with new EBook dbus implementation

[Milan Crha <mcrha redhat com>]

On Fri, 2011-05-27 at 11:59 -0400, Matthew Barnes wrote:
> On Fri, 2011-05-27 at 16:49 +0200, Milan Crha wrote: 
> > Maybe it can pump them, but it doesn't deliver them, as far as my tests
> > showed, because they are usually delivered on idle, which never happen
> > with blocked main loop. That's the reason why I added there this loop.
> > Only notice that this loop is running for "sync" calls, and only if it's
> > done from the main thread. The async calls and sync calls from a
> > dedicated thread doesn't do any such thing. You may not use sync calls
> > in your application, preferably. (Same as evolution shouldn't, which is
> > subject to change, to use the EBOok/CalClient APIs directly.)
> 
> Can't we just consider it a programming error for a D-Bus method to be
> called synchronously from the main thread?  I don't see any reason to
> support this case since it would be by definition a bug.
> 
> In fact I'd go so far as to emit a runtime warning about it and return
> immediately we detect that case.  Historically we've been not very good
> about this sort of thing, and failing loudly might help flush out any
> remaining blocking issues buried in Evolution or other parts of E-D-S.

Hehe, quite cruel idea, though as long as Evolution itself uses
EBook/ECal, then we may keep it this way, because before such change
will be done the most of evo would be unusable.

But I take your idea and I like it. I only wish we have easier way of
detecting whether the function is called in the main thread or a
dedicated thread, down in the GLib, preferably with
g_thread_is_main(GThread *thread) usually called with thread =
g_thread_self(); because playing with main context ownership seems to me
like a gross hack (and maybe it sometimes even doesn't work, but that's
just my feeling, no proof so far).
	Bye,
	Milan