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 _______________________________________________ evolution-hackers mailing list firstname.lastname@example.org To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers