On Fri, 2011-05-27 at 16:49 +0200, Milan Crha wrote: > On Fri, 2011-05-27 at 13:01 +0200, Alexander Larsson wrote: > > I needed the most recent eds to test the folks eds backend, and I picked > > up the new dbus EBook APIs. Unfortunatelly that seemed to be completely > > broken for me (evolution contacts hanged, test-self in the tests > > hanged), so I have debugged it. Turns out that it was sending a dbus > > signal like get_contact_done but the code was expecting a > > getContact_done signal. > > > > Patches to fix this at: > > https://bugzilla.gnome.org/show_bug.cgi?id=651147 > > Hi, > which test did you run? The > tests/libebook/client/test-client-get-contact > doesn't hang for me. I'm moving to your bug report with further > investigation on this, though on the first look I think of avoiding > camel-cased DBus function names and keep them only with underscores. > It's easier to search/grep for them too.
I'm running tests/libebook/test-self. Adding a more detailed analysis of it to: https://bugzilla.gnome.org/show_bug.cgi?id=651147#c13 > > Furthermore, I don't see why this is required at all. GDBus (for this > > very reason, amongst others) does all its i/o in a worker thread and > > should be able to pump messages even while the main thread is blocking. > > 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.) True, true, they are recieved on a thread and delivered on a mainloop (via an idle). However can control which mainloop they get delivered to by calling g_main_context_push/pop_thread_default() around the dbus message send, which allows you to create a new main context + loop (g_main_context_new, g_main_loop_new) with nothing else in, then you can run this mainloop with g_main_loop_run which is safe since all it will do is handle the dbus signal. Anyway, I agree that you shouldn't use sync calls, especially evolutions. But, if they are there, something will call it. So, either make the sync calls not reenter, or remove them. _______________________________________________ evolution-hackers mailing list email@example.com To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers