On Di, 2011-05-10 at 08:40 +0100, Dumez, Christophe wrote: > Please find attached a few patches for QtContacts EDS backend: > 0001: Make the contact save/remove requests really asynchronous. This > should increase performance because the async requests can now > actually run in parallel instead of sequentially. It also > improved/rewrote the contacts saving/removing code at the same time (I > save one DBus round-trip in contact removing for example). > 0002: ut_filtering: Slight async request improvement and more debug > output > 0003: ut_signals: More debug output
All looks good to me. Admittedly, I am now only looking at obvious code deficiencies and check that it runs and compiles for me. The tests still fail to run for me, but I merged anyway for the time being. We should stop patching EDS separately and instead start a devel:eds sub-project in OBS where we package the necessary bits and pieces. That way we can be sure that we really use the same environment => https://bugs.meego.com/show_bug.cgi?id=17355 > I added the two last patches to help debugging a possible race > condition in EDS: The ut_signals test sometimes fails for me because I > get a contactsChanged() signal back instead of a contactsAdded() one > for one of the two contacts although e_book_add_contact_async() is > called for both contacts. It might be related to ID reuse since the > previous unit test has contacts that get the same ids (they are > properly removed at the end of the test though). I suspected that this happens because EDS buffers changes for a short period, then combines multiple changes into a single EBookView update D-Bus message. But notify_add() in e-data-book-view.c ensures that deletes and changes are flushed first. So I need to look more deeply. -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
