Isso é fora de escopo 
, é tipo dizer que o problema em uma página de erro 500 está no Browser do usuário mesmo claramente sendo um erro de servidor, se o processo é anexado ao matar a janela, mata-se o processo, perceba: o processo da janela problemática é SEMPRE identificado, o exato oposto do que você disse:
A questão é, em todos os cenários que você citou: o software é dividido em cliente/servidor, você tem 2 processos independentes problemáticos: o cliente que não trata excessões e faz a janela congelar e o servidor que gera a excessão que o cliente não trata
Enfim, o problema não está em não corresponder a janela ao processo problemático, o problema está em ter 2 processos independentes (importante ressaltar) e problemáticos onde 1 tem uma janela e por consequência simples de descobrir e matar e o outro não possui janela
1 curtida
Não existe algo como “fora do escopo” aqui, não existe um “alemão de verdade” seria o mesmo que eu dizer que só porque o KDE tem um análogo do xkill no Wayland, o problema não existe no Wayland porque o restante dos casos está “fora de escopo”, ou porque Gnome, KDE e a maioria das DEs sabem matar sozinhos janelas cuja thread principal para de responder (mesma coisa que o Wndows faz para detectar estes casos e por um label de “não responde”).
Se você quiser você pode colocar arbitrariamente a margem do problema no lugar que preferir, eu vejo diferente, travamentos e congelamentos de processos locais são uma coisa mal resolvida em todos os OSes não existem casos que não são “travamentos de verdade”.
Perceba o que eu disse: tem 2 processos independentes com problemas, um é fácil por ter uma janela o outro não, não seria fora de escopo se os processos fosse diretamente ligados mas não é o que ocorre, nos casos em que você citou os processos podem até estar em máquinas diferentes, o gerenciador de tarefas consegue identificar o processo problemático atrelado a janela em teoricamente 100% dos casos desde o SDK do Vista, isso é ponto pacífico, inclusive nenhum dos exemplos que você citou inválida essa afirmação…
Pra finalizar: Enfim como eu disse o modelo cliente servidor foge de escopo por ser 2 processos independentes, e ambos podem ser problemáticos se uma “janela” (cliente) espera uma resposta de um processo de segundo plano (servidor) e ela congela por não obter essa resposta, é nítido que essa janela que congelou tem um problema de excessão não tratada e por consequência o gerenciador de tarefas vai apontar esse problema, o problema no servidor não é relacionado a janela o cliente deve ser fail-safe em relação ao servidor… Essa é minha última resposta entenda se quiser, tá bem explícito porque é fora de escopo
Estes aplicativos são projetados para o servidor estar na mesma máquina do cliente, funcionando como um serviço local, definitivamente o aplicativo trava estando na mesma máquina. Não muda o fato de que matar o processo não está fora do alcance do sistema.
Não, não é, é somente ponto pacífico que como qualquer outro OS, o Windows é capaz de definir programas como travados, apenas cuja thread principal, responsável pela interface gráfica e tratamento de eventos, esteja bloqueada:
There are many different root causes for application hangs, and not all of them manifest themselves in an unresponsive UI.
…
The operating system defines an application hang as a UI thread that has not processed messages for at least 5 seconds
Mesmo sem ter um processo totalmente separado, um app pode travar sem congelar a interface gráfica, o travamento pode ocorrer dentro do mesmo processo, em uma threads secundárias e/ou processos sem interface gráfica locais do qual ele depende (serviço).
[quote=“Natanael.755, post:23, topic:56374”]
Enfim como eu disse o modelo cliente servidor foge de escopo por ser 2 processos independentes[/quote]
Eu continuo não achando isso e acho que o conceito que a Microsoft dá, em que todos estes casos são vistos como travamentos de app, é o correto. O usuário não vai olhar e dizer “ufa… Ainda bem que este travamento não é um travamento de verdade.”
Cara, são processos independentes e diferentes, pelo que você respondeu parece que vc está como se servidor e cliente fossem o mesmo processo mas em threads diferentes, mas não é o caso, são processos inteiros separados, um antivírus (Avast por exemplo) tem o Avast Service que é o responsável por geralmente monitorar em tempo real, disparar escaneamento sob demanda pelo menu de contexto e por aí vai, e o Avast que apresenta a interface, perceba que se uma tread falha, a interface (como você mesmo mostrou) pode ficar normalmente responsiva
A questão aqui, de novo: se uma janela (Avast) por exemplo, não tá responsiva por n motivos, você pode matar o processo da janela, se ao reiniciar o processo a janela voltar a ficar irresponsiva por causa de um processo de fundo, não significa que o gerenciador de tarefas falhou, significa que ele resolveu uma parte do problema
A discussão desde o começo era sobre travamento de aplicativos ou processos. A própria documentação da Microsoft aponta que este tipo de problema não se resume somente a estes casos particulares onde a interface gráfica não responde.
E por N motivos isso pode resolver absolutamente nada, e igualmente a interface gráfica pode não estar congelada, e ainda assim teremos um travamento de aplicativo.
É por isso que eu pessoalmente não acho que nem xkill, nem o atalho do KDE, nem as DEs detectando e pedindo se o programa deve ser encerrado, ou o Windows listando lá no gerenciador de tarefas, resolve melhor.
Absolutamente todas estas soluções fazem a mesma coisa, resolvem uma parte do problema, a mesma parte, da mesma forma limitada.
Aqui no Arch (Gnome), nunca vi acontecer dessa forma.
Já vi o Wayland travar no emulador Yuzu (flatpak), mas instalando por AppImage, deixou de travar.
Essa GPU em particular, precisa de um reballing acredito, é da NVIDIA, ajustando o clock dela, ela ia mais longe ou menos longe, mas sempre, 1 ou 2 vezes por dia ela se corrompia, até que mês passado desisti e movi ela para Windows. Ela enxia a tela de riscos e travava o Xorg ou Wayland, fosse KDE ou Gnome. No Windows ela funciona indefinidamente, sem precisar de ajuste no clock. Nem sempre foi assim, começou ano passado.
Neste reporte de bug que citei, é possível ter uma noção do problema, lembrando que esse reporte é no mesa então cobre só questões da AMD e Intel, e é sobre a AMD em particular e o seu mecanismo de recuperação. Mas eu não ficaria surpreso se variasse de acordo com setup e hardware, o próprio issue tem posts comentando que KDE + Intel conseguem recuperar.