[evolution-data-server/gnome-3-20] [IMAPx] Release idle_lock before disconnecting the cancellable

commit b59863d88df30dc8a55f32efc2d469654f17faa8
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]