[Bug 73599] Shutdown delay in GNOME caused by inhibitor introduced in mission-control 5.15.1

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=73599

--- Comment #4 from Michael Kuhn <suraia at ikkoku.de> ---
(In reply to comment #3)
> The intended functionality is:
> 
> * when we're told we're sleeping or shutting down, we start trying to
> disconnect all active connections
> * when all active connections have returned from their async Disconnect
> method (or in particular, immediately if there are no active connections),
> we release the inhibitor
> 
> As far as I can tell, you're changing this to:
> 
> * when we're told we're sleeping or shutting down, we start trying to
> disconnect all active connections (e.g. send "</stream:stream>" on XMPP)
> * without waiting for that, we release the inhibitor
> * if the user is unlucky, the system will sleep or shut down before the
> "</stream:stream>" (or whatever) has reached the server, and the server
> still thinks they're connected
> 
> which is not what we want?

As far as I can tell, it still works like this. The inhibitor is ref counted,
that is, the release before sleeping/shutting down only decrements the ref
count. However, the connections still hold references:

Upon disconnect, the state-change signal is emitted with the inhibitor attached
to it; this is processed in mcd-account.c and trickles down to
mcd-connection.c, which "holds" the inhibitor (that is, increases the ref
count) and calls tp_cli_connection_call_disconnect(). When disconnect is
finished, the inhibitor is "released" (that is, the ref count is decremented
again).

The logs show that the last connection to disconnect decreases the ref count to
0 and actually releases the inhibitor.

Sorry for not being more clear about this. :-)

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.