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

[Alexander Larsson <alexl redhat com>]

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.