Travaux imbriqués

Une application peut utiliser des travaux imbriqués pour gérer des sous-ensembles de processus. Les travaux imbriqués permettent é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 : processus A 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 et du comportement des travaux imbriqués :

• hiérarchies de travaux imbriquées
• création d’une hiérarchie de travaux imbriquée
• limites et notifications des travaux imbriqués
• Comptabilité 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 de son travail parent. Si un processus déjà présent 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 aucun travail ne définit les limites d’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 du travail 2 et du travail 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 le 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 travaux parente du travail 3. Le travail final 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ée

Les processus d’une hiérarchie de travaux sont explicitement associés à un objet de travail à l’aide de la fonction AssignProcessToJobObject ou implicitement associées lors de la création du processus, comme pour les travaux autonomes. L’ordre dans lequel les travaux sont créés et les processus sont affecté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 doivent être appelés plusieurs fois pour que chaque processus associe le processus à chaque travail auquel il doit appartenir. Pour vous assurer que la hiérarchie de travaux est valide, affectez tout d’abord tous les processus au travail à la racine de la hiérarchie, puis affectez un sous-ensemble de processus à l’objet de travail enfant immédiat, et ainsi de suite. Si les 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 requis pour l’imbrication. Si les processus sont affectés à des travaux dans un ordre aléatoire, à un moment donné, un travail enfant aura des processus qui ne figurent pas dans son travail parent. Cela n’est pas autorisé par l’imbrication et entraîne l’échec de AssignProcessToJobObject.

Lorsque les 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 dans la chaîne de travaux parente, en déplaçant la hiérarchie jusqu’à ce qu’elle atteigne un travail qui n’autorise pas la rupture. 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 parent l’autorisent.

Limites et notifications des travaux imbriqués

Pour certaines limites de ressources, la limite définie pour les travaux dans une chaîne de tâches parente détermine la limite effective appliquée pour un travail enfant. La limite effective pour le 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 son travail parent 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 le nombre minimal et maximal de la plage de travail. Pour plus d’informations sur les limites de ressources spécifiques, consultez SetInformationJobObject.

Lorsque certains événements se produisent, tels que la nouvelle violation de la création de processus ou de la limite de ressources, un message est envoyé au port d’achèvement d’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é 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.

Comptabilité 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 ci-dessous dans la chaîne de travaux.

Arrêt des travaux imbriqués

Lorsqu’un travail dans une hiérarchie de travaux est arrêté, le système met fin aux processus de ce travail et de 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 disposer du droit d’accès JOB_OBJECT_TERMINATE, identique à celui des travaux autonomes.