Travaux imbriqués
Une application peut utiliser des travaux imbriqués pour gérer des sous-ensembles de processus. Les travaux imbriqués activent également une application qui utilise des travaux pour héberger d’autres applications qui utilisent également des travaux.
Windows 7, Windows Server 2008 R2, Windows XP avec SP3, Windows Server 2008, Windows Vista et Windows Server 2003 : Un processus ne peut être associé qu’à un seul travail. Les travaux imbriqués ont été introduits dans Windows 8 et Windows Server 2012.
Cette rubrique fournit une vue d’ensemble de l’imbrication des travaux et du comportement des travaux imbriqués :
- Hiérarchies de travaux imbriquées
- Création d’une hiérarchie de travaux imbriquées
- Limites des travaux et notifications pour les travaux imbriqués
- Gestion des ressources pour les travaux imbriqués
- Arrêt des travaux imbriqués
Pour obtenir des informations générales sur les travaux et les objets de travail, consultez Objets de travail.
Hiérarchies de travaux imbriquées
Les travaux imbriqués ont une relation parent-enfant dans laquelle chaque travail enfant contient un sous-ensemble des processus dans son travail parent. Si un processus qui se trouve déjà dans un travail est ajouté à un autre travail, les travaux sont imbriqués par défaut si le système peut former une hiérarchie de travaux valide et qu’aucun travail ne définit les limites de l’interface utilisateur (SetInformationJobObject avec JobObjectBasicUIRestrictions).
La figure 1 montre une hiérarchie de travaux qui contient une arborescence de processus étiquetés P0 à P7. Le travail 1 est le travail parent des travaux 2 et 4, et il s’agit d’un ancêtre du travail 3. Le travail 2 est le parent immédiat du travail 3 ; Le travail 3 est l’enfant immédiat du travail 2. Les travaux 1, 2 et 3 forment une chaîne de travaux dans laquelle les travaux 1 et 2 sont la chaîne de travail parente de l’emploi 3. Le travail de fin dans une chaîne de travaux est le travail immédiat des processus de ce travail. Dans la figure 1, le travail 3 est le travail immédiat des processus P2, P3 et P4.
Les travaux imbriqués peuvent également être utilisés pour gérer des groupes de processus homologues. Dans la hiérarchie des travaux illustrée dans la figure 2, le travail 1 est le travail parent du travail 2. Notez qu’une hiérarchie de travaux peut contenir uniquement une partie d’une arborescence de processus. Dans la figure 2, P0 n’est pas dans la hiérarchie, mais ses processus enfants P1 à P5 sont.
Création d’une hiérarchie de travaux imbriquées
Les processus d’une hiérarchie de travaux sont soit explicitement associés à un objet de travail à l’aide de la fonction AssignProcessToJobObject , soit implicitement associés lors de la création du processus, comme pour les travaux autonomes. L’ordre dans lequel les travaux sont créés et les processus attribués détermine si une hiérarchie peut être créée.
Pour créer une hiérarchie de travaux à l’aide d’une association explicite, tous les objets de travail doivent être créés à l’aide de CreateJobObject, puis AssignProcessToJobObject doit être appelé plusieurs fois pour que chaque processus associe le processus à chaque travail auquel il doit appartenir. Pour vous assurer que la hiérarchie du travail est valide, affectez d’abord tous les processus au travail à la racine de la hiérarchie, puis attribuez un sous-ensemble de processus à l’objet de travail enfant immédiat, et ainsi de suite. Si des processus sont affectés à des travaux dans cet ordre, un travail enfant aura toujours un sous-ensemble de processus dans son travail parent pendant la création de la hiérarchie, ce qui est nécessaire pour l’imbrication. Si des processus sont affectés à des travaux dans un ordre aléatoire, à un moment donné, un travail enfant aura des processus qui ne se trouvent pas dans son travail parent. Cela n’est pas autorisé par l’imbrication et entraîne l’échec de AssignProcessToJobObject .
Lorsque des processus sont implicitement associés à un travail lors de la création du processus, un processus enfant est associé à chaque travail de la chaîne de travaux de son processus parent. Si l’objet de travail immédiat autorise l’interruption, le processus enfant s’éloigne de l’objet de travail immédiat et de chaque travail de la chaîne de travaux parente, en se déplaçant vers le haut de la hiérarchie jusqu’à atteindre un travail qui ne permet pas l’interruption. Si l’objet de travail immédiat n’autorise pas l’interruption, le processus enfant ne s’interrompt pas même si les travaux de sa chaîne de travaux parente le permettent.
Limites des travaux et notifications pour les travaux imbriqués
Pour certaines limites de ressources, la limite définie pour les travaux dans une chaîne de travaux parente détermine la limite effective qui est appliquée pour un travail enfant. La limite effective du travail enfant peut être plus restrictive que la limite de son parent, mais elle ne peut pas être moins restrictive. Par exemple, si la classe de priorité d’un travail enfant est ABOVE_NORMAL_PRIORITY_CLASS et que la classe de priorité de sa tâche parente est NORMAL_PRIORITY_CLASS, la limite effective des processus dans le travail enfant est NORMAL_PRIORITY_CLASS. Toutefois, si la classe de priorité du travail enfant est BELOW_NORMAL_PRIORITY_CLASS, la limite effective des processus dans le travail enfant est BELOW_NORMAL_PRIORITY_CLASS. Les limites effectives sont appliquées pour la classe de priorité, l’affinité, les frais de validation, la limite de temps d’exécution par processus, la limite de classe de planification et l’ensemble de travail minimal et maximal. Pour plus d’informations sur les limites de ressources spécifiques, consultez SetInformationJobObject.
Lorsque certains événements se produisent, tels que la création d’un nouveau processus ou une violation de la limite des ressources, un message est envoyé au port d’achèvement des E/S associé à un travail. Un travail peut également s’inscrire pour recevoir des notifications lorsque certaines limites sont dépassées. Pour un travail non imbriqué, le message est envoyé au port d’achèvement d’E/S associé au travail. Pour un travail imbriqué, le message est envoyé à chaque port d’achèvement d’E/S associé à n’importe quel travail dans la chaîne de travaux parente du travail qui a déclenché le message. Un travail enfant n’a pas besoin d’avoir un port d’achèvement d’E/S associé pour les messages qu’il déclenche pour être envoyés aux ports d’achèvement d’E/S des travaux parents plus haut dans la chaîne de travaux. Pour plus d’informations sur des messages spécifiques, consultez JOBOBJECT_ASSOCIATE_COMPLETION_PORT.
Gestion des ressources pour les travaux imbriqués
Les informations de comptabilité des ressources pour un travail imbriqué décrivent l’utilisation de chaque processus associé à ce travail, y compris les processus dans les travaux enfants. Chaque travail d’une chaîne de travaux représente donc les ressources agrégées utilisées par ses propres processus et les processus de chaque travail enfant en dessous dans la chaîne de travail.
Arrêt des travaux imbriqués
Lorsqu’un travail d’une hiérarchie de travaux est arrêté, le système met fin aux processus de ce travail et à tous ses travaux enfants, en commençant par le travail enfant en bas de la hiérarchie. Les ressources en attente utilisées par chaque processus terminé sont facturées au travail parent.
Le handle de travail doit avoir le droit d’accès JOB_OBJECT_TERMINATE, comme pour les travaux autonomes.