[Autogenerated] the main problem with nested jobs in terms of tools
is that the Windows API doesn't really provide any specific way to
distinguish child jobs from parent jobs.
The basic idea is that when you look at a particular job,
you see everything from that job down to all the
child jobs that may or may not exist.
So going to process explore, for instance,
if we just double-click something,
we can see there's a job here that has a single process,
but there's no direct way to tell whether this process is a direct
process in this job or whether there is a child job to this job and
one of its process happens to be this one,
there's really no way to tell because from an api perspective or
from really from the way things work perspective,
it doesn't really matter.
It's the only thing that matters is the job that these processes are seen.
So the actual limits that are being applied regardless of where this
is coming from a direct job or some parent job.
So we see from the job in question all the way down to any
child job that may or may not exist.
So there's no direct way to actually say whether we
are part of a child job or not.
By the way, here's a different job using edge here.
So Edge is in a job,
you can see various limits here that are set in terms of ui such as
the ability to read and write the clipboards,
you can't copy paste from outside or to the outside of this job.
This is one thing that you can see here and there's some
other stuff like processed memory limit here.
And so we can try to find nested jobs in some way,
usually using really just dumb luck.
So for example, this job has many, many processes.
So maybe there's a child job here somewhere and we started looking at that job.
Let's see if we can find this one again.
Let me find the object here,
which is a job that has this weird looking name and that's okay.
These names are allowed.
And now that we have the object address,
let's look at that for a perspective of a job.
And let's look at the process list for this job and you can see
that there's zero processes assigned to this job,
which means that there is actually the processes are
part of some child job for this job.
So how can we see that?
So there's another flag.
The job command which has the value for this value is undocumented.
And again,
I think this is just some oversight on the part of
whoever has written documentation, but it shows child jobs.
So once we do that,
we can see there's lots of output here and at some point actually
recursive to the child jobs as many as they are.
So you can see child jobs here starts and it shows the child jobs and
any child jobs of that which apparently exists.
It shows those child jobs as well with whatever parameters they have.
And this one doesn't have additional child jobs and then we have another
job which is part of the Children of the previous job.
And this one also has no further child jobs.
Here's another child job from the root job and and so on.
So it requires is it makes it a bit difficult perhaps to watch all
the details there and you can get a sense of whether there is some
child job for this job by looking at the D.
T.
Command with the job data structure, let's grab this and see what's going on.
So this data structure is like I said,
they're pretty big and we can guess many of its members because they
make sense in terms of managing jobs for instance.
So you can see here stuff like the statistics that are being
accumulated as part of the accounting information.
You can see there's a process links,
head that you can probably guess is being the list entry,
the head of the list of all the processes that belong to this job.
The job links is the link to the next and previous jobs that are
held in that global list of jobs that I mentioned,
but at some point you'll find members that manage the hierarchy.
So for instance, you can see sibling job links,
this is the list of all the siblings for this particular job.
And here's the child jobless thead So that's the first child,
you can see the parent job if there is any,
you can see the root job.
So the root job is the uppermost parent and you can see it exists,
but there's no direct parents.
So obviously this is also serving as uh as the root.
In fact, that's the this particular job, that's the same value.
So it's the root of itself here, and because there's zero processes,
it means that you have other other jobs here and you can see
that at least in terms of the Children, which you can look at as well.
So in general,
you can get a sense of the fact that there are some uh members here that
give you a hint of the fact that there are child jobs,
but there's no easy way to see that except for using these four value here
as the number of the detail from an api perspective,
it's completely transparent if you call something like cray information job
object to get a list of all the processes in the job,
you'll get all the processes in this job and any child jobs of this
job and there is really no distinction there.
So you can't really tell whether you have child jobs or not.
And again from functionality perspective doesn't really matter,
but maybe from curiosity perspective or some kind of analysis,
it might be interesting,
but currently there are no APIs you can use in user mode to get that information