Re: Not quite out of the pipestatus woods yet ...

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

On Sat, 26 Oct 2013 09:57:46 -0700
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> HOWEVER, with the "setopt MONITOR" added before the stress test, I have
> had the shell go into a fast busy in acquire_pgrp() -- the while loop
> condition never becomes false but the shell never gets SIGT* either.

(Could perhaps be the same problem as the "i'm sorry, I can't do that
without a terminal, dave" race with a function at the end of the
pipeline?)
 
> I think that's a separate problem, but:  PWS, do you remember enough
> about why there is an assumption that oldjobtab never needs to be set
> back to NULL once it has been created?  Or is this just a case of not
> realizing that printjob() has multiple responsibilities, including the
> reaping of old jobs?

Orignally, I'm pretty sure (because for once I can remember doing it;
perhaps the coffee machine was broken) that oldjobtab was created to
allow you to look at the main shell's jobs from a subshell; they
wouldn't be updated any more, but users weren't too worried about the
races as they just wanted e.g. to be able to pipe the output of jobs in
a one-off fashion.  In that case, of course, there's no question of
doing anything with it; it remains the same ancient history of the
origignal shell until the subshell dies.  There was also no question of
job control in a subshell in those days --- that came significantly
later --- so copying it and clearing the main jobtab, rather than using
the latter in situ and assuming it was frozen, may just have been
caution.

If oldjobtab has suffered mission creep since then, there's a good
chance that any additional circumstance has been overlooked.

pws