JOBS /K ... how does it work?

May 20, 2008
10,497
77
Syracuse, NY, USA
If I do this in a "host" TCC,
Code:
jobs /n=job1 /k
start
jobs /n=job1 %_startpid
jobs /n=job1 /i
I see that the STARTed TCC was added to the job. But that process doesn't terminate when the host process terminates.

In comparison, if I
Code:
jobs /n=job1 /k
start /job=job1
jobs /n=job1 /i
I also see that the new TCC was added to the job, and in this case that new TCC terminates when the host TCC terminates.

In the first example above, I'd expect all handles to the job object to be closed when the host TCC exits, but that's apparently not so because the "/K" isn't working.

What is the difference?
 
May 20, 2008
10,497
77
Syracuse, NY, USA
OK but there's still a fundamental difference between the way these two behave.
Code:
jobs /n=job1 /k
start
jobs /j=job1 %_startpid
and

Code:
jobs /n=job1 /k
start /job=job1
When the host TCC terminates, the STARTed TCC does not terminate in the first scenario above and does terminate in the second. Is that expected behavior? As far as I can tell, the "/K" property of a job only works for child processes started with "START /JOB=".
 
May 20, 2008
10,497
77
Syracuse, NY, USA
In your first example, TCC has to duplicate the job handle in the START'd process. So exiting the host TCC process still leaves an open handle in the other process.
I suppose wanting the job processes to terminate along with the controlling process would be a common use of a job object. If the help mentioned "START /JOB=" along with the "/K" option, I might not be asking the same questions every couple of years. :-)

In my BTM, I'm also using
Code:
jobs /n=job1 /k
start /job=job1 %prog1
start /job=job1 %prog2
on break ( jobs /j=job1 /c & quit)
This is a nice way (more polite than TASKEND /F) to terminate the child processes when I Ctrl-C out of the BTM.