@ magicandre1981 Cette page propose un moyen de vérifier qu'un programme effectue activement quelque chose, mais ce n'est pas la manière dont Windows l'utilise réellement.
Kevin Panko
Regardez la file de messages Windows, un candidat est la fonction PeekMessage ()
Luciano
Réponses:
150
Une application obtient les événements d'une file d'attente fournie par Windows.
Si l'application n'interroge pas la file d'événements pendant un certain temps (5 secondes), par exemple lors d'un calcul long, Windows considère alors que l'application est bloquée et en avertit l'utilisateur.
Pour éviter cela, les applications devraient imposer des calculs coûteux aux threads de production ou diviser le traitement et s'assurer que la file d'attente est interrogée régulièrement.
↑ ceci. Rien à voir avec la planification ou tel que suggéré dans la réponse acceptée, que si vous appelez régulièrement GetMessage(ou similaire) et DispatchMessage.
Damon
1
La réponse acceptée, en se référant IsHungAppWindowcorrectement, indique qu’un programme en phase de démarrage n’a pas à appeler GetMessage.
MSalters
@MSalters Avec le démarrage étant défini comme le temps avant le premier GetMessage? Cette fonctionnalité permet aux applications simples en ligne de commande de fonctionner sans être considérées comme bloquées, car elles n'ont pas besoin d'interroger la file d'attente.
Monstre à cliquet
4
@ratchetfreak: probablement avant le premier appel à CreateWindow. Les applications en ligne de commande sont différentes bêtes; ils tournent dans ConHost.EXE et cela interagit avec le sous-système graphique de Windows pour eux.
MSalters
1
de plus, il me semble que dans Windows 7 (et peut-être plus tôt), Windows le remarquera beaucoup plus tôt si vous essayez de ne pas manipuler la fenêtre d'une manière ou d'une autre. comme si un programme ne
Dave Cousineau
78
Comment Windows sait-il qu'un programme ne répond pas?
Sans le code source de Windows, nous ne pouvons pas être sûr de ce qu'il fait en interne.
Il existe une fonction Windows du SDK IsHungAppWindowpouvant être utilisée.
Une application est considérée comme ne répondant pas si elle n’attend pas l’entrée, si elle n’est pas en cours de traitement et si PeekMessage n’a pas appelé PeekMessage dans le délai de temporisation interne de 5 secondes.
Si une fenêtre de niveau supérieur cesse de répondre aux messages pendant plus de plusieurs 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 présentant le même ordre Z, le même emplacement, la même taille et les mêmes attributs visuels. Cela permet à l'utilisateur de le déplacer, de le redimensionner ou même de fermer l'application. Cependant, ce sont les seules actions disponibles car l'application ne répond pas.
L'état de blocage n'est pas basé sur le processeur. La plupart des programmes sont "bloqués" dans ce sens 99,999% du temps et ne font rien.
usr
2
@usr Où ai-je dit que "accroché" dépend de la CPU?
DavidPostill
2
@usr La première moitié de la réponse répond "Est-ce qu'il continue à interroger toutes les applications en cours d'exécution?". La seconde partie répond "Comment Windows sait-il si un programme ne répond pas?. Le PO posait deux questions en une;)
DavidPostill
9
Ce n'est pas vraiment un sondage, n'est-ce pas? Je suppose que les éléments internes ressemblent davantage à une poignée d'attente sur la fenêtre qui est signalée lorsque vous appelez PeekMessage. Ainsi, lorsque Windows envoie un message à l'application et ne reçoit pas de signal dans les cinq secondes, il marque l'application comme ne répondant pas. Et en fait, sur les fenêtres plus récentes, la fenêtre est seulement marquée "ne répond pas" si elle ne répond pas à la saisie de l' utilisateur à temps - jusqu'à ce que j'essaie de cliquer ou d'appuyer sur une touche ou quelque chose, l'application peut facilement rester "bloquée" pendant minutes sans "paraître" non réactif.
Luaan
2
Vous pouvez supprimer tout ce qui précède "À propos des messages et des files de messages", car cela n’aidera pas la réponse. Windows sait qu'une application a cessé de répondre parce qu'elle arrête de pomper des messages. L’application peut être exécutée de manière intensive, au lieu de diffuser des messages (mais c’est un programme mal conçu).
Andy
32
En réalité, 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 conclue que l'application ne répond pas.
Par exemple, Windows n'a aucun moyen de savoir si une application de traitement des chiffres sans interface utilisateur exécutée à partir de la ligne de commande fait son travail, ou peut-être bloquée dans une boucle infinie.
Les applications graphiques interactives sous Windows reçoivent les événements en interrogeant en permanence une file de messages. Windows remplit cette file de messages avec des événements de type clavier, souris, minuterie, etc. Si une application ne parvient pas à interroger la file de messages pendant un certain temps (5 secondes correspond au délai mentionné dans la documentation de la fonction IsHungAppWindow ()), Windows considère l'application "bloquée", ce qu'elle peut indiquer en modifiant le titre de la fenêtre (ajout du texte " (Ne répond pas) "ou un texte équivalent dans les versions localisées) et grise le contenu de la fenêtre si l'utilisateur tente d'interagir avec la fenêtre.
Les applications peuvent se bloquer d'une manière non reconnue par Windows. Par exemple, une application peut continuer à interroger des messages dans sa file d'attente sans y donner suite correctement. Ainsi, à toutes fins pratiques, elle semblerait "bloquée" sans que Windows se rende compte qu'elle ne répond pas.
Ne pas répondre, par définition, signifie ne pas traiter les messages de la fenêtre. Par conséquent, cela ne s'applique pas aux services ni aux applications de la console. Je dirais donc que Windows sait toujours si une application ne répond pas. Vous confondez serrures et ne répondez pas.
Andy
Bien sûr, il peut savoir si un programme ne répond pas. "Ne pas répondre" n'est pas la même chose que "coincé dans une boucle infinie"
BlueRaja - Danny Pflughoeft
1
En fait, une application peut récupérer des messages via GetMessage () sans les traiter, et Windows ne reconnaîtra pas le message "ne répond pas", alors qu'elle ne semblerait certainement pas répondre aux attentes de son utilisateur. Le terme "ne pas répondre" est également souvent utilisé pour décrire des applications de réseau, de service, de ligne de commande interactive, etc. À ma connaissance, il n’existe pas de définition formelle limitant l’expression aux applications fenêtrées. Un blocage ou une boucle infinie (ou toute autre erreur de programmation) peut empêcher une application de répondre, mais non, je n'ai pas confondu le lien de cause à effet.
Viktor Toth
10
Windows est un système d'exploitation, il supervise tous les programmes en cours d'exécution.
Windows communique avec des applications basées sur une fenêtre à l'aide d'événements. Chaque programme a un fil qui écoute en permanence les événements entrants et les traite. Par exemple, lorsque vous cliquez sur un bouton ou une icône de zone de notification, Windows génère un événement et le transmet au processus approprié. Le processus peut alors décider comment le gérer.
Toutes les interactions avec les programmes sont basées sur des événements dans Windows. Par conséquent, si le programme ne traite pas les événements entrants trop longtemps, cela signifie qu'il ne répond pas. Comme @DavidPostill a constaté et noté dans sa réponse , le délai d'attente est de 5 secondes. PeekMessageest la fonction qui obtient un événement de la file d'attente d'événements.
Alors que le système d’exploitation Windows peut et doit interroger des applications avec des événements dans la file d’attente Windows, les programmes n’ont absolument aucune obligation de se lier à WinAPI ou de gérer / répondre à la file d’attente Windows. Même répondre à un message dans la file d'attente n'indique pas à Windows si le programme est "bloqué" ou non. C'est un indicateur, mais c'est tout. La vraie réponse est un peu plus compliquée.
La vraie réponse
Les gens se concentrent sur la réponse réelle ici. Déterminer si un programme "ne répond pas" est une variante du " problème stoppant ", qui est formellement indécidable en informatique. En résumé, le processeur ne peut pas agir en tant que tiers s’observant lui-même pour déterminer si un sous-programme est bloqué dans une boucle infinie, sans rien faire ni incrémenter un compteur qui se terminera à un certain nombre fixe et normal. Ces deux peuvent être considérés comme des boucles étroitement fermées. L'un s'arrête, l'autre ne se terminera jamais. Même vous, en tant que personne, ne savez pas si un programme réagit réellement ou non, surtout s'il est dans une boucle bien fermée - vous savez seulement si pensez-le qu'il devrait (répondre).
Du point de vue de Windows, ces deux boucles "ne répondent pas" . C'est pourquoi Windows vous donne le choix d'attendre ou de terminer, car elle ne peut pas dire.
Ainsi , le corollaire est « pourquoi ne fenêtres savent qu'un processus est répond? » La réponse est plutôt intelligente. Lorsqu'un processus est compilé dans un système d'exploitation multi-thread et multi-processus, parfois même dans des boucles étroitement fermées, le compilateur peut ajouter une commande yield () , qui indique au processeur qu'il peut basculer vers d'autres processus en cours d'exécution. . Il « donne » le processeur et un « changement de contexte » (comme on l'appelle) arrive qui permet au système d' exploitation (Windows inclus) pour répondre à d' autres événements dans la pile, dont certaines comprennent le suivi que le processus a réagi.
** Cela ne signifie pas qu'un processus de réponse va se terminer . ** Un processus à l'intérieur d'une boucle infinie peut produire le processeur, permettant à Windows de traiter d'autres événements.
Dans certains programmes Windows, le programme gère 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, monopolisant le processeur et ne se terminant pas dans les langages de niveau supérieur de Windows tels que perl, php, python et Windows, peuvent ne pas détecter qu'il ne se termine pas et ne répond pas. À ce stade, Windows dépend d'heuristiques - 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 à la procédure, car il ne sait vraiment pas s’il le faut.
Voir aussi la réponse (correcte) de Viktor. Ignorez les commentaires indiquant si "ne pas répondre" n'est pas la même chose qu'une boucle infinie. Il existe toutes sortes de messages, interruptions, boucles qu'une application peut gérer ou non sans informer la file de messages Windows. La gestion de la file de messages n’est qu’un des nombreux types d’événements sur lesquels le système d’exploitation conserve les compteurs pour essayer de deviner si un processus est suspendu.
Réponses:
Une application obtient les événements d'une file d'attente fournie par Windows.
Si l'application n'interroge pas la file d'événements pendant un certain temps (5 secondes), par exemple lors d'un calcul long, Windows considère alors que l'application est bloquée et en avertit l'utilisateur.
Pour éviter cela, les applications devraient imposer des calculs coûteux aux threads de production ou diviser le traitement et s'assurer que la file d'attente est interrogée régulièrement.
la source
GetMessage(ou similaire) etDispatchMessage.IsHungAppWindowcorrectement, indique qu’un programme en phase de démarrage n’a pas à appelerGetMessage.GetMessage? Cette fonctionnalité permet aux applications simples en ligne de commande de fonctionner sans être considérées comme bloquées, car elles n'ont pas besoin d'interroger la file d'attente.Comment Windows sait-il qu'un programme ne répond pas?
Sans le code source de Windows, nous ne pouvons pas être sûr de ce qu'il fait en interne.
Il existe une fonction Windows du SDK
IsHungAppWindowpouvant être utilisée.Fonction source IsHungAppWindow
Source à propos des messages et des files de messages
T-il constamment interroger toutes les applications en cours d'exécution?
Non, les applications ne sont pas interrogées, mais leur temps de traitement est long.
Windows dispose d'un système de planification qui alloue du temps processeur aux threads d'application.
L'algorithme de planification est complexe et est décrit en détail dans Windows Internals, Part 1 (6th Edition) (Référence du développeur) .
la source
PeekMessage. Ainsi, lorsque Windows envoie un message à l'application et ne reçoit pas de signal dans les cinq secondes, il marque l'application comme ne répondant pas. Et en fait, sur les fenêtres plus récentes, la fenêtre est seulement marquée "ne répond pas" si elle ne répond pas à la saisie de l' utilisateur à temps - jusqu'à ce que j'essaie de cliquer ou d'appuyer sur une touche ou quelque chose, l'application peut facilement rester "bloquée" pendant minutes sans "paraître" non réactif.En réalité, 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 conclue que l'application ne répond pas.
Par exemple, Windows n'a aucun moyen de savoir si une application de traitement des chiffres sans interface utilisateur exécutée à partir de la ligne de commande fait son travail, ou peut-être bloquée dans une boucle infinie.
Les applications graphiques interactives sous Windows reçoivent les événements en interrogeant en permanence une file de messages. Windows remplit cette file de messages avec des événements de type clavier, souris, minuterie, etc. Si une application ne parvient pas à interroger la file de messages pendant un certain temps (5 secondes correspond au délai mentionné dans la documentation de la fonction IsHungAppWindow ()), Windows considère l'application "bloquée", ce qu'elle peut indiquer en modifiant le titre de la fenêtre (ajout du texte " (Ne répond pas) "ou un texte équivalent dans les versions localisées) et grise le contenu de la fenêtre si l'utilisateur tente d'interagir avec la fenêtre.
Les applications peuvent se bloquer d'une manière non reconnue par Windows. Par exemple, une application peut continuer à interroger des messages dans sa file d'attente sans y donner suite correctement. Ainsi, à toutes fins pratiques, elle semblerait "bloquée" sans que Windows se rende compte qu'elle ne répond pas.
la source
Windows est un système d'exploitation, il supervise tous les programmes en cours d'exécution.
Windows communique avec des applications basées sur une fenêtre à l'aide d'événements. Chaque programme a un fil qui écoute en permanence les événements entrants et les traite. Par exemple, lorsque vous cliquez sur un bouton ou une icône de zone de notification, Windows génère un événement et le transmet au processus approprié. Le processus peut alors décider comment le gérer.
Toutes les interactions avec les programmes sont basées sur des événements dans Windows. Par conséquent, si le programme ne traite pas les événements entrants trop longtemps, cela signifie qu'il ne répond pas. Comme @DavidPostill a constaté et noté dans sa réponse , le délai d'attente est de 5 secondes.
PeekMessageest la fonction qui obtient un événement de la file d'attente d'événements.la source
La réponse à votre question est oui / non.
Alors que le système d’exploitation Windows peut et doit interroger des applications avec des événements dans la file d’attente Windows, les programmes n’ont absolument aucune obligation de se lier à WinAPI ou de gérer / répondre à la file d’attente Windows. Même répondre à un message dans la file d'attente n'indique pas à Windows si le programme est "bloqué" ou non. C'est un indicateur, mais c'est tout. La vraie réponse est un peu plus compliquée.
La vraie réponse
Les gens se concentrent sur la réponse réelle ici. Déterminer si un programme "ne répond pas" est une variante du " problème stoppant ", qui est formellement indécidable en informatique. En résumé, le processeur ne peut pas agir en tant que tiers s’observant lui-même pour déterminer si un sous-programme est bloqué dans une boucle infinie, sans rien faire ni incrémenter un compteur qui se terminera à un certain nombre fixe et normal. Ces deux peuvent être considérés comme des boucles étroitement fermées. L'un s'arrête, l'autre ne se terminera jamais. Même vous, en tant que personne, ne savez pas si un programme réagit réellement ou non, surtout s'il est dans une boucle bien fermée - vous savez seulement si pensez-le qu'il devrait (répondre).
Du point de vue de Windows, ces deux boucles "ne répondent pas" . C'est pourquoi Windows vous donne le choix d'attendre ou de terminer, car elle ne peut pas dire.
Ainsi , le corollaire est « pourquoi ne fenêtres savent qu'un processus est répond? » La réponse est plutôt intelligente. Lorsqu'un processus est compilé dans un système d'exploitation multi-thread et multi-processus, parfois même dans des boucles étroitement fermées, le compilateur peut ajouter une commande yield () , qui indique au processeur qu'il peut basculer vers d'autres processus en cours d'exécution. . Il « donne » le processeur et un « changement de contexte » (comme on l'appelle) arrive qui permet au système d' exploitation (Windows inclus) pour répondre à d' autres événements dans la pile, dont certaines comprennent le suivi que le processus a réagi.
** Cela ne signifie pas qu'un processus de réponse va se terminer . ** Un processus à l'intérieur d'une boucle infinie peut produire le processeur, permettant à Windows de traiter d'autres événements.
Dans certains programmes Windows, le programme gère 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, monopolisant le processeur et ne se terminant pas dans les langages de niveau supérieur de Windows tels que perl, php, python et Windows, peuvent ne pas détecter qu'il ne se termine pas et ne répond pas. À ce stade, Windows dépend d'heuristiques - 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 à la procédure, car il ne sait vraiment pas s’il le faut.
Voir aussi la réponse (correcte) de Viktor. Ignorez les commentaires indiquant si "ne pas répondre" n'est pas la même chose qu'une boucle infinie. Il existe toutes sortes de messages, interruptions, boucles qu'une application peut gérer ou non sans informer la file de messages Windows. La gestion de la file de messages n’est qu’un des nombreux types d’événements sur lesquels le système d’exploitation conserve les compteurs pour essayer de deviner si un processus est suspendu.
la source