Como o Windows sabe se um programa não está respondendo? Ele continua constantemente pesquisando todos os aplicativos em execução?
Um aplicativo obtém os eventos de uma fila fornecida pelo Windows.
Se o aplicativo não pesquisar o eventqueue por um tempo (5 segundos), por exemplo, ao fazer um cálculo longo, o Windows presumirá que o aplicativo está interrompido e alerta o usuário.
Para evitar que os aplicativos enviem cálculos dispendiosos para segmentos de trabalho ou divida o processamento e verifique se a fila é pesquisada regularmente.
Sem o código-fonte para o Windows, não podemos ter certeza do que está fazendo internamente.
Existe uma função do Windows do SDK IsHungAppWindow que pode ser usada.
An application is considered to be not responding if it is not waiting for input, is not in startup processing, and has not called PeekMessage within the internal timeout period of 5 seconds.
Fonte função IsHungAppWindow
If a top-level window stops responding to messages for more than several seconds, the system considers the window to be not responding. In this case, the system hides the window and replaces it with a ghost window that has the same Z order, location, size, and visual attributes. This allows the user to move it, resize it, or even close the application. However, these are the only actions available because the application is actually not responding.
Fonte Sobre mensagens e filas de mensagens
Não. As aplicações não são pesquisadas, mas recebem o tempo do processador.
O Windows possui um sistema de agendamento que dá tempo ao processador para threads de aplicativos.
O algoritmo de agendamento é complexo e está totalmente descrito em Internos do Windows, Parte 1 (6ª Edição) (Referência do Desenvolvedor) .
Na verdade, o Windows nem sempre sabe que um aplicativo não está respondendo. O aplicativo deve ser um aplicativo interativo com uma janela, e a janela deve estar recebendo mensagens que o aplicativo não consegue processar, antes que o Windows conclua que o aplicativo não está respondendo.
Por exemplo, o Windows não tem como saber se um aplicativo de processamento de números sem interface de usuário que é executado a partir da linha de comando está fazendo a sua parte, ou talvez preso em um loop infinito.
Aplicativos gráficos interativos no Windows recebem eventos ao pesquisar continuamente uma fila de mensagens. O Windows preenche essa fila de mensagens com eventos de teclado, mouse, timer etc. Se um aplicativo não pesquisar a fila de mensagens por algum tempo (5 segundos é o tempo limite mencionado na documentação da função IsHungAppWindow ()), o Windows considera o aplicativo "interrompido", o que pode indicar alterando o título da janela (adicionando o texto " (Não está respondendo) "ou texto equivalente em versões localizadas) e mostrando o conteúdo da janela se o usuário tentar interagir com a janela.
Os aplicativos podem travar de maneiras que o Windows não reconhece. Por exemplo, um aplicativo pode continuar pesquisando mensagens em sua fila de mensagens sem agir adequadamente sobre elas, portanto, para todos os fins e propósitos práticos, ele pareceria "interrompido" sem o Windows reconhecer que não é responsivo.
O Windows é um sistema operacional, está supervisionando todos os programas em execução.
O Windows se comunica com aplicativos baseados em janelas usando eventos. Todo programa tem um thread que constantemente escuta eventos de entrada e os processa. Por exemplo, quando você clica em um botão ou em um ícone da área de notificação, o Windows gera um evento e o alimenta no processo apropriado. O processo pode então decidir como lidar com isso.
Todas as interações com programas são baseadas em eventos no Windows, portanto, quando o programa não processa eventos recebidos por muito tempo, isso significa que ele não responde. Como @DavidPostill encontrou e anotou em sua resposta , o tempo limite é de 5 segundos. PeekMessage é a função que obtém um evento da fila de eventos.
A resposta para sua pergunta é sim / NÃO.
Embora o sistema operacional Windows possa e faça poll de aplicativos com eventos na Fila do Windows Messaging, os programas não têm absolutamente nenhuma obrigação de vincular-se ao WinAPI ou de manipular / responder a Fila do Windows. Mesmo responder a uma mensagem na fila não informa ao Windows se o programa foi "bloqueado" ou não. É um indicador, mas é tudo o que é. A resposta real é um pouco mais complicada.
A verdadeira resposta
As pessoas estão se protegendo da resposta real aqui. Determinar se um programa "não está respondendo" é uma variante do " problema de parada ", formalmente indecidível na ciência da computação. A breve explicação é que o processador não pode atuar como um terceiro observando-se para determinar se uma sub-rotina está presa em um loop infinito, não fazendo nada contra incrementar um contador que terminará em algum número normal fixo. Ambos podem ser considerados como loops bem fechados. Um pára, o outro nunca terminará. Mesmo você, como pessoa, não sabe se um programa está realmente respondendo ou não, especialmente se estiver em um loop bem fechado - você só sabe se acha que deveria (responder).
Do ponto de vista do Windows, esses dois loops são "não respondendo" . É por isso que o Windows lhe dá a opção de esperar ou finalizar, porque não é possível dizer.
Portanto, o corolário é "por que o Windows sabe que um processo está respondendo?" A resposta é bastante inteligente. Quando um processo é compilado em um & multi-threaded & sistema operacional multi-processo, às vezes até em loops bem fechados, o compilador pode adicionar um comando yield () , que fornece uma notificação conveniente ao processador que pode alternar para outros processos em execução. Ele "desiste" do processador e um "switch de contexto" (como é chamado) acontece e permite que o SO (Windows incluído) responda a outros eventos na pilha, alguns dos quais incluem rastreamento de que o processo tem respondeu.
** Isso não significa que um processo de resposta terminará . ** Um processo dentro de um loop infinito pode render o processador, permitindo que o Windows processe outros eventos.
Em alguns programas do Windows, o programa lidará com os sinais do sistema operacional Windows, que podem dizer ao SO que ele está "respondendo", mas nenhum programa tem qualquer obrigação de fazê-lo. Você pode escrever programas simples e sem terminação de CPU, mesmo dentro de linguagens de alto nível no Windows, como perl, php, python, e o Windows pode não detectar que não está encerrando e não está respondendo. Nesse ponto, o Windows depende de heurísticas - carga da CPU, memória, quantas interrupções o processador processou enquanto o programa estava sendo executado para "adivinhar". Novamente, nesse ponto, o Windows tem que pedir para você terminar, porque ele realmente não sabe se deveria.
Veja também a resposta (correta) de Viktor. Ignore os comentários sobre se "não responder" não é o mesmo que um loop infinito. Existem todos os tipos de mensagens, interrupções, loops que um aplicativo pode ou não manipular sem informar a fila de mensagens do Windows. O manuseio da fila de mensagens é apenas um dos muitos tipos de eventos que o SO mantém em contadores para tentar adivinhar se um processo está suspenso.
Tags windows