Comment Windows sait-il qu'un programme ne répond pas ?

Comment Windows sait-il qu'un programme ne répond pas ?

Sans le code source de Windows, nous ne pouvons pas être sûrs de ce qu'il fait en interne.

Il existe une fonction SDK Windows IsHungAppWindow qui peuvent être utilisés.

Une application est considérée comme ne répondant pas si elle n'attend pas d'entrée, n'est pas en cours de traitement de démarrage, et n'a pas appelé PeekMessage dans le délai d'attente interne de 5 secondes.

Source : Fonction IsHungAppWindow

Si une fenêtre de niveau supérieur cesse de répondre aux messages pendant plus de quelques secondes, le système considère que la fenêtre ne répond pas. Dans ce cas, le système masque la fenêtre et la remplace par une fenêtre fantôme qui a le même ordre Z, le même emplacement, la même taille et les mêmes attributs visuels. L'utilisateur peut ainsi la déplacer, la redimensionner ou même fermer l'application. Cependant, ce sont les seules actions disponibles car l'application ne répond pas.

Source : À propos des messages et des files d'attente de messages

Est-ce qu'il interroge constamment toutes les applications en cours ?

Non. Les applications ne sont pas interrogées mais bénéficient d'un temps de traitement.

Windows dispose d'un système d'ordonnancement qui accorde du temps processeur aux threads d'application.

L'algorithme d'ordonnancement est complexe et est décrit en détail dans le document suivant Windows Internals, Part 1 (6e édition) (Référence pour les développeurs) .

En fait, Windows ne sait pas toujours qu'une application ne répond pas. L'application doit être une application interactive avec une fenêtre, et la fenêtre doit recevoir des messages que l'application ne parvient pas à traiter, avant que Windows ne conclue que l'application ne répond pas.

Par exemple, Windows n'a aucun moyen de savoir si une application de calcul sans interface utilisateur, exécutée à partir de la ligne de commande, est en train de faire son travail ou si elle est bloquée dans une boucle infinie.

Les applications graphiques interactives de Windows reçoivent des événements en interrogeant continuellement une file d'attente de messages. Windows alimente cette file d'attente de messages avec des événements liés au clavier, à la souris, à la minuterie, etc. Si une application ne parvient pas à interroger la file d'attente des messages pendant un certain temps (5 secondes est le délai mentionné dans la documentation de la fonction IsHungAppWindow()), Windows considère que l'application est "suspendue", ce qu'il peut indiquer en modifiant le titre de la fenêtre (en ajoutant le texte "(Not Responding)" ou un texte équivalent dans les versions localisées) et en grisant le contenu de la fenêtre si l'utilisateur tente d'interagir avec celle-ci.

Les applications peuvent se bloquer d'une manière que Windows ne reconnaît pas. Par exemple, une application peut continuer à rechercher des messages dans sa file d'attente sans y donner suite, de sorte qu'à toutes fins utiles, elle semble "suspendue" sans que Windows ne reconnaisse qu'elle ne répond pas.

Windows est un système d'exploitation, il supervise tous les programmes en cours.

Windows communique avec les applications basées sur les fenêtres en utilisant des événements. Chaque programme possède un fil d'exécution qui écoute constamment les événements entrants et les traite. Par exemple, lorsque vous cliquez sur un bouton ou sur l'icône d'une zone de notification, Windows génère un événement et le transmet au processus approprié. Le processus peut alors décider de la manière de le traiter.

Dans Windows, toutes les interactions avec les programmes sont basées sur des événements. Ainsi, lorsqu'un programme ne traite pas les événements entrants pendant trop longtemps, cela signifie qu'il ne répond pas. Comme @DavidPostill l'a trouvé et noté dans sa réponse le délai d'attente est de 5 secondes. PeekMessage est la fonction qui récupère un événement de la file d'attente des événements.

La réponse à votre question est oui/non.

Bien que le système d'exploitation Windows puisse interroger les applications avec des événements dans la file d'attente de messagerie Windows, les programmes ne sont absolument pas obligés de se lier à l'interface WinAPI ou de traiter/répondre à la file d'attente Windows. Même le fait de répondre à un message dans la file d'attente ne permet pas à Windows de savoir si le programme est "verrouillé" ou non. C'est un indicateur, mais c'est tout ce qu'il est. La vraie réponse est un peu plus compliquée.

La vraie réponse

Les gens tournent autour de la vraie réponse ici. Déterminer si un programme "ne répond pas" est une variante de la méthode de "l'erreur de réponse". problème de l'arrêt ", qui est formellement indécidable en informatique. En bref, le processeur ne peut pas agir comme une tierce partie qui s'observe elle-même pour déterminer si une sous-routine est coincée dans une boucle infinie, ne fait rien ou incrémente un compteur qui se terminera à un nombre fixe et normal. Ces deux cas peuvent être considérés comme des boucles fermées. L'une s'arrête, l'autre ne se terminera jamais. Même vous, en tant que personne, ne savez pas si un programme répond ou non, surtout s'il est dans une boucle fermée -- vous ne savez que si pense qu'il devrait (répondre).

Du point de vue de Windows, ces deux boucles sont "ne répond pas" . C'est pourquoi Windows vous donne le choix d'attendre ou de terminer, car il ne peut pas le dire.

Le corollaire est donc "pourquoi Windows sait-il qu'un processus es qui répond ?" La réponse est plutôt astucieuse. Lorsqu'un processus est compilé dans un système d'exploitation multithread et multiprocessus, parfois même dans des boucles étroitement fermées, le compilateur peut ajouter une fonction rendement() qui permet de signaler au processeur qu'il peut passer à d'autres processus en cours. Il "abandonne" le processeur et un "changement de contexte" (comme on l'appelle) se produit, ce qui permet au système d'exploitation (Windows inclus) de répondre à d'autres événements dans la pile, dont certains incluent le suivi que le processus a répondu.

**Cela ne signifie pas qu'un processus de réponse sera résilier . ** Un processus dans une boucle infinie peut céder le processeur, permettant à Windows de traiter d'autres événements.

Dans certains programmes Windows, le programme traitera les signaux du système d'exploitation Windows, ce qui peut indiquer au système d'exploitation qu'il "répond", mais aucun programme n'est obligé de le faire. Vous pouvez écrire des programmes très simples qui accaparent le CPU et ne se terminent pas, même dans des langages de plus haut niveau sous Windows tels que perl, php, Python, et Windows peut ne pas détecter qu'il ne se termine pas et ne répond pas. À ce stade, Windows dépend de l'heuristique - charge du processeur, mémoire, nombre d'interruptions traitées par le processeur pendant l'exécution du programme - pour "deviner". Encore une fois, à ce stade, Windows doit vous demander de mettre fin au programme, car il ne sait pas vraiment s'il doit le faire.

Voir aussi la réponse (correcte) de Viktor. Ignorez les commentaires sur le fait que "ne pas répondre" n'est pas la même chose qu'une boucle infinie. Il existe toutes sortes de messages, d'interruptions, de boucles qu'une application peut ou non traiter sans en informer la file d'attente des messages de Windows. La gestion de la file d'attente des messages n'est que l'un des nombreux types d'événements sur lesquels le système d'exploitation garde des compteurs pour tenter d'identifier les éléments suivants devinez si un processus est suspendu.