[Autogenerated] now let's take a look at nested jobs.
So when jobs were first created, in fact up until Windows ain't,
you could assign a process to a single job only and this provides a very
frustrating limit at times because if you have a process you would like to
control in some way by putting it into one job that you you control and that
process happens to be already part of the job,
you're out of luck,
there's nothing you can do about it because we know that the process,
once it enters the job, it can never leave that job.
So if you try to assign a process to a second job, this would simply fail.
And that was kind of frustrating and limited the way jobs could
be utilized on the window system In Windows eight or later and
later this limitation was lifted.
So now you can create the process and have that
process assigned to more than one job.
Well,
you don't have to create the process whatever
process you have a powerful handle,
to you can add to more than one job and in most cases that would succeed,
which would create a job hierarchy if the this is possible.
So there are some cases which which also this will also fail.
But these cases should be fairly rare.
So now it's possible to add the process to more than one job in one sense,
this was kind of necessary because UWP processes that we looked at earlier in
these scores are always part of the job and we know that the job uses the
Deep freeze functionality to suspend the process.
And so it was it would be very kind of problematic if you could
just use that particular job for the process and you couldn't add
the process to a different job that had perhaps different limits
you might want to apply.
And so that extension had to be somehow somehow created and Windows 18 later
supported and in case that we have this nested job hierarchy,
The only rule is that a parent job has more power than a child job.
So in case of conflict, parent job always wins out.
So essentially a child job can create something which is more
restrictive but not more permissive than its parent job,
that's the only requirement.
And if you try to go against that that requirement,
simply the limit you provide will be ignored if they go against or become
more um more permissive than the parent job provided.
So here's an example of how nested jobs get created here.
We have a job A currently without any processes.
So let's say I'm adding process P one to job.
So now process P one is affected by job only.
Now we're adding process P one to a second job job be.
So what happens here assuming job B was just a separate job.
Previously job B becomes a child of job A and the hierarchy is now formed.
So now p one is affected by job A and by job be whatever
limits are applied and in case of conflict,
the more restrictive is the limits they are applied.
And then suppose I'm adding process P two to job.
Then as usual, process P two is now affected by job A.
If I add process P.
Two to some job.
See then again the hierarchy continues to be built and now Job A.
Has two child jobs, Job B and Job C and P.
Two as before, is now affected by job C.
And job.
Eh So here's the interesting part lets them adding process P.
Three to Job be.
Only I'm not necessarily aware of job A.
Regardless because of the existing hierarchy,
P three is going to be affected by job A.
And the job be even though P.
Three perhaps wasn't put into job explicitly and the one that he's
controlling job B is not necessarily aware of job A.
P three regardless, is also affected by the limits provided by job A and Job be.
So, let's see if we can see some of these things using tools