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 Woodhouse intel com Intel Corporation
Attachment:
smime.p7s
Description: S/MIME cryptographic signature