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 However, looking at the internals made me worry about some details. First of all, gdbus_proxy_call_sync() when called on the main thread will recurse the mainloop. This (mainloop recursion) is considered very bad practice and should only be done very explicitly. Unchecked reentrancy like this can cause all sorts of weird problems and was the main reason bonobo failed. For instance, a single call to a sync EBook API can reenter the mainloop, handle a gdk destroy event and close the main window of your app, or call *any* other apis in the whole app. To correctly handle this all internal state must be consistent and after return from any sync call you must assume all internal state may have changed. This is not something most apps can do, especially when this is happening in some lowlevel addressbook api call. 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. Secondly, why is it using a dbus signal for the done callbacks? Wouldn't it be more sane to use a direct message (without expecting a reply)? A signal will be sent to everyone subscribing to that signal, which will be all clients talking to the EBook, not just the one that requested the operation (i.e. called getContact()). _______________________________________________ evolution-hackers mailing list email@example.com To change your list options or unsubscribe, visit ... http://mail.gnome.org/mailman/listinfo/evolution-hackers