If we use it without grouping changes into transactions by using e_book_sqlite_lock(), and if we have a cancellation in the calls to actually make the changes, then this warning triggers because the new cancellation doesn't match the NULL that we have stored for the non-existent overall transaction.
Yes, we probably ought to be using locking in EWS but we're not. It's
perfectly valid to make changes without a transaction lock. Shut up
about it.
---
addressbook/libedata-book/e-book-sqlite.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/addressbook/libedata-book/e-book-sqlite.c
b/addressbook/libedata-book/e-book-sqlite.c
index 0ae89cd..9e5cb78 100644
--- a/addressbook/libedata-book/e-book-sqlite.c
+++ b/addressbook/libedata-book/e-book-sqlite.c
@@ -209,7 +209,7 @@ ebsql_init_debug (void)
#define EBSQL_LOCK_OR_RETURN(ebsql, cancellable, val) \
G_STMT_START { \
EBSQL_LOCK_MUTEX (&(ebsql)->priv->lock); \
- if (cancellable != NULL && \
+ if (cancellable != NULL && (ebsql)->priv->cancel && \
(ebsql)->priv->cancel != cancellable) { \
g_warning ("The GCancellable passed to `%s' " \
"is not the same as the cancel object " \
--
1.9.3
--
David Woodhouse Open Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
