Re: Shell job structure

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

Just to tie this off, as we now have this mostly addressed:

On Oct 8,  9:44pm, Peter Stephenson wrote:
} Subject: Shell job structure
}
} On Mon, 07 Oct 2013 07:40:49 -0700
} Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
} > - because external jobs can exit and be reaped in arbitrary order, even
} >   in a pipeline, the job table is used to keep track of which position
} >   in the array to update

More specifically:  The "procs" linked list in a job table entry keeps
track of the array positions.  The complication is ..

} > - jobs that run in the current shell don't have a complete job table entry

... and the "incomplete" part is that there *is* a job table entry, but
the current shell task doesn't have an entry in the "procs" list.

} >   [cf. all the gyrations to suspend/background a loop] and aren't "reaped"
} >   in the same code path as external jobs, so the wrong array position (or
} >   none at all) may get updated

Because zsh "forks to the left" to keep the tail of the pipeline in the
current shell, the status of the current shell task has to be added to
the end of $pipestatus (internally "pipestats"), which means an accurate
count of the number of other processes in the pipeline is essential.

} > - the incorrect update depends on whether the external job exited AND got
} >   reaped before the current-shell job has completed, because of the way
} >   reaping updates the job table, so correctness is unpredictable

This has been fixed by moving the update of pipestats to the point where
the job table entry is deleted, instead of trying to do it at the point
where individual processes have their status updated.

} > - complex commands "in the current shell" may have external subjobs that
} >   need a separate pipestatus (this applies only at end of a pipeline)

I believe this has also been worked around by the above, but one thing
we haven't tested yet is what value $pipestatus has *inside* a loop.

} The job table would become a list of top-level jobs, while the job
} structure would have pointers to nested jobs.

As I mentioned elsewhere, the procs list and "other" pointer into the
job table serve this function.

It still might be done more cleanly, but at least we avoided a full
rewrite for now.