|
Processus / Handles
Les "Handles" comme les "processus", sont vraiment spécifiques à l'environnement windows, on retrouve ces termes sur d'autres OS, mais ils ont alors une signification bien différente, ce qui peut porter à confusion... Donc, dans mon explication, il ne faut pas perdre de vue qu'on suppose être sous environnement windows, sans extension possible à d'autres OS:
Pour le coup, l'explication est très simple, plus que pour les "thread" :
________________________________________________
PROCESSUS
________________________________________________
Un processus, c'est un générateur de "thread", ça peut être un programme simple, comme un programme complexe qui peut alors générer plusieurs processus. D'ailleurs, il y a fort à parier qu'un soft programmé en vue du MP ou du HP (multi/hyper threading) génère plusieurs processus...
Un bon exemple: les anti-virus et firewall genèrent un grand nombre de processus, qui sont d'ailleurs prompt à ralentir un système de façon mesurable.
Dans le cas d'un TSR (programme résident style "drivers" ou "gestionnaire d'interruption") le programme est terminé mais son ou ses processus restent actif aussi longtemps que le même programme ne vient pas les supprimer, seul windows peut les supprimer de lui-même en cas d'erreur ou de demande par l'utilisateur:
Programme
|
|
V
un ou plusieurs processus
|
|
V
un ou plusieurs thread
Pourquoi avoir intercalé des processus entre les programmes et les threads ? C'est une notion assez récente, qui n'existait pas sous environnement 16 bits, il y a quelques années. C'est ce qui a permis à windows de devenir multitâche "prehemptif" et limiter les crashs système à chaque erreur dûe à un programme.
C'est pour ça que c'est spécifique à windows, si vous entendez parlez de "processus" sous un autre OS, ça n'aura sûrement la même signification...
_______________________________________________
HANDLE:
_______________________________________________
Là aussi, spécifique à windows quoique existant sous d'autres OS utilisants les systèmes de fichiers FAT 16 / 32 / NTFS.
Le concept du "handle" est très simple, un programme se lance et a besoin pour ses fonctions de 2 ou 3 librairies de type ".Dll" et 2 ou 3 fichiers graphiques comme des ".bmp" ou des ".gif", le programme génère autant de handles que de fichiers nécessaires à son fonctionnement tout simplement parce-ce que deux programmes ne peuvent pas acceder à un fichier en même temps. C'est comme une "reservation", pour eviter que d'autres programmes accèdent par megarde à ces fichiers et génèrent un erreur dans le meilleurs, voir un crash dans le cas d'un fichier système.
Le fait que windows ne permette pas à deux programmes d'acceder à un même fichier simultanéement pose des gros problèmes de performance donc une parade a été trouvé par le devellopeurs windows, la création de fichiers "fantômes", c'est à dire la copie d'un fichier demandé dans la mémoire: un programme "demande" un handle sur 10 fichiers pour s'éxécuter, windows, si il le peut va générer 10 fichiers "fantôme" dans la RAM et générer de lui-même 10 nouveaux handles de telle manière qu'un autre programme pourra quand même utiliser ces même 10 fichiers sur le disque ou à nouveau dans la RAM sous forme de fantômes supplementaire (déjà 30 handles generés !).
Windows lui-même est un énorme générateur de handles car chaque icone (puisque c'est fichier) est également un handles, la barre des tâche, chaque fenêtre, chaque élément graphique de windows suceptible d'être modifiable est un handles et réside sur le disque ou dans la RAM du PC...
Autre sens du terme:
Un "handle" en terme de programmation bas niveau (asm / C++) est un mode d'adressage des fichiers au DOS ou à windows, elle co-existe avec une autre méthode appelé "FCB".
Trophy.
|
Mode linéaire
