[evolution-data-server] [IMAPx] Release idle_lock before disconnecting the cancellable
- From: Milan Crha <mcrha src gnome org>
- To: commits-list gnome org
- Cc:
- Subject: [evolution-data-server] [IMAPx] Release idle_lock before disconnecting the cancellable
- Date: Mon, 11 Apr 2016 13:20:52 +0000 (UTC)
commit 53dcb9889e2c5cb589a1354b93d06a05d37446ba
Author: Milan Crha <mcrha redhat com>
Date: Mon Apr 11 15:10:35 2016 +0200
[IMAPx] Release idle_lock before disconnecting the cancellable
There could happen a deadlock when one thread was stopping the IDLE thread
while another thread was cancelling the same cancellable in the disconnect
phase. It could be that the stop_idle thread was holding the idle_lock, while
the other thread was holding the GCancellable's global lock (for example
as part of the g_cancellable_cancel() call) and also waiting for the idle_lock
due to the idle_cancellable being cancelled.
Let's unlock the idle_lock before disconnecting the cancellable, thus these
two locks do not overlap.
camel/providers/imapx/camel-imapx-server.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
---
diff --git a/camel/providers/imapx/camel-imapx-server.c b/camel/providers/imapx/camel-imapx-server.c
index 3924c83..d01f464 100644
--- a/camel/providers/imapx/camel-imapx-server.c
+++ b/camel/providers/imapx/camel-imapx-server.c
@@ -6382,6 +6382,8 @@ camel_imapx_server_stop_idle_sync (CamelIMAPXServer *is,
g_cond_wait (&is->priv->idle_cond, &is->priv->idle_lock);
}
+ g_mutex_unlock (&is->priv->idle_lock);
+
if (cancellable && handler_id)
g_cancellable_disconnect (cancellable, handler_id);
@@ -6395,8 +6397,6 @@ camel_imapx_server_stop_idle_sync (CamelIMAPXServer *is,
"Reconnect after cancelled IDLE stop command");
}
- g_mutex_unlock (&is->priv->idle_lock);
-
if (!success) {
if (idle_cancellable)
g_cancellable_cancel (idle_cancellable);
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]