Re: Crash on jobstates since workers/49783 (commit 6a8aa2a)

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Mon, Mar 28, 2022 at 9:14 AM Peter Stephenson
<p.w.stephenson@xxxxxxxxxxxx> wrote:
>
> We have two options here: either keep jobstates for top level jobs
> and introduce a separate one for the last thing started in the current
> shell, or decide on the fly that we're no longer interested in the
> parent shell.

It's not just "the last thing started" that's wanted, it's a list of
every process that was started.  So although it's a bit magical that
backgrounding a job clears the job table, that seems the better of
those two alternatives.

Another possibility that occurs to me is for the values in $jobstates to change.

     ... The keys are the job numbers and the values
     are strings of the form 'JOB-STATE:MARK:PID=STATE...'.  The
     JOB-STATE gives the state the whole job is currently in, one of
     'running', 'suspended', or 'done'.

What if JOB-STATE became "parent" in the subshell?  Or something along
those lines.  I guess that goes back to having to make a deep copy of
the saved job structure.

Incidentally:

% sleep 10 & print -aC2 ${(kv)jobstates}; (jobs -l; print -aC2 ${(kv)jobstates})
[1] 69151
1  running:+:69151=running
[1]  + 69151 running    sleep 10
1  running:+

How is it that "jobs -l" still knows the PID from the parent job, but
$jobstates cannot report it?