_NET_WM_PING
A forma como o gerenciador de janelas descobre se um aplicativo travou, e a propriedade de PID que depois permite matar o processo certo.
O servidor X nunca percebe que um programa parou de responder: a conexão está aberta, a janela está desenhada e os cliques se acumulam educadamente no buffer do servidor. O EWMH deu ao gerenciador de janelas um teste. Um programa que listou _NET_WM_PING em WM_PROTOCOLS recebe, de vez em quando e sempre que o usuário aperta o botão de fechar, uma ClientMessage com um timestamp e o ID da própria janela, que ele deve devolver intacta à janela raiz. A resposta sai do laço de eventos do programa, então um programa preso num cálculo ou numa chamada bloqueante não responde, e depois de alguns segundos o gerenciador pode concluir que ele travou. É daí que vem o diálogo "o aplicativo não está respondendo" do Mutter e do KWin. GTK e Qt respondem ao ping dentro do toolkit, de modo que quem programa o aplicativo nunca o vê.
Matar um programa X é mais difícil do que parece. XKillClient apenas fecha a conexão, e um processo que não a esteja escutando segue em frente sem janela, tranquilamente. Por isso o EWMH também pôs _NET_WM_PID na janela, permitindo ao gerenciador enviar SIGKILL ao processo certo após uma resposta perdida — depois de comparar WM_CLIENT_MACHINE com o próprio hostname, já que um PID de outra máquina não significa nada. Contêineres e Flatpak, com seus próprios namespaces de PID, tornaram o truque pouco confiável de novo, uma lição que o Wayland aprendeu: lá o cliente responde aos pings dentro do próprio protocolo, e o compositor conhece o processo pelo socket.