KillWindow support for Wayland windows
ClosedPublic

Authored by graesslin on Nov 15 2016, 4:40 PM.

Details

Summary

AbstractClient gains a new pure virtual killWindow method and this gets
implemented in ShellClient.

ShellClient performs the killing by sending a term signal to the
process. This can only work if the client connected through the socket
and didn't get a socketpair fd passed. In that case the pid is KWin's
and KWin doesn't want to terminate. Thus this is special handled to
destroy the connection instead.

In case terminating the process has no effect, the connection gets
destroyed after five seconds.

The KillWindow is adjusted to operate on AbstractClient instead of
Client.

This implements T4463.

Test Plan

Killed windows and auto test

Diff Detail

Repository
R108 KWin
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.
graesslin updated this revision to Diff 8172.Nov 15 2016, 4:40 PM
graesslin retitled this revision from to KillWindow support for Wayland windows.
graesslin updated this object.
graesslin edited the test plan for this revision. (Show Details)
graesslin added reviewers: KWin, Plasma on Wayland.
Restricted Application added projects: Plasma on Wayland, KWin. · View Herald TranscriptNov 15 2016, 4:40 PM
Restricted Application added subscribers: kwin, plasma-devel. · View Herald Transcript
cfeck added a subscriber: cfeck.Nov 15 2016, 8:31 PM

5 seconds seems long in the face of a user. But if the application does actually handle the termination signal, and needs more than 5 seconds for cleanup, does it mean the cleanup procedure will be interrupted/aborted, or is only the GUI connection disconnected?

In D3370#62908, @cfeck wrote:

5 seconds seems long in the face of a user. But if the application does actually handle the termination signal, and needs more than 5 seconds for cleanup, does it mean the cleanup procedure will be interrupted/aborted, or is only the GUI connection disconnected?

The GUI connection gets disconnected which will raise a Wayland error on client side. How the application handles this is toolkit specific. In case of QtWayland it will result in an ::exit(1)

And it's also no guarantee that the window will be gone. In case of Qt it works as the Wayland connection is hold in another thread, so if the main thread is frozen and cannot react to the sigterm, the destroy of the Wayland connection will still work.

So overall the 5 sec are a main-thread freeze protection and could be changed in whatever way we want.

mart accepted this revision.Nov 16 2016, 11:27 AM
mart added a reviewer: mart.
This revision is now accepted and ready to land.Nov 16 2016, 11:27 AM
This revision was automatically updated to reflect the committed changes.