[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 #3 from Simon McVittie <simon.mcvittie at collabora.co.uk> ---
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?

>From the log on the GNOME bug,

(process:4846): mcd-DEBUG: monitor_state_changed_cb: account idle/irc/SaadM0
must disconnect
(process:4846): mcd-DEBUG: monitor_state_changed_cb: account idle/irc/SaadM1
must disconnect
(process:4846): mcd-DEBUG: monitor_state_changed_cb: account
gabble/jabber/saamalik_40gmail_2ecom0 must disconnect

Unfortunately, MC doesn't currently log the beginning and end of the
Disconnect() call. Perhaps you could try this with a "disposable" Gabble
account, and get the corresponding Gabble log too?

One possible refinement is: here is the life-cycle of a connection:

[0]
MC -> connection manager: RequestConnection
[1]
MC <- connection manager: RequestConnection reply
[2]
MC <-> connection manager: (some setup)
[2]
MC -> connection manager: Connect
[3]
MC <- connection manager: Connect reply
[3]

If we're in state [0], MC should release the inhibitor immediately: simple.

If we're in state [3], to make a best-effort attempt to disconnect from the
server, we have to call Disconnect, and wait for it to finish before releasing
the inhibitor.

If we're in state [2], we can call Disconnect to discard the connection, but we
don't *have* to do that before suspending/shutting down; so we could call
Disconnect on it, but release the inhibitor immediately without waiting.

If we're in state [1], we can't even call Disconnect until we reach state [2]
(we don't have anything to disconnect yet!), but once again, we can release the
inhibitor without waiting.

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