Re: Shell job structure

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Oct 25, 11:00am, Peter Stephenson wrote:
} Subject: Re: Shell job structure
}
} On Thu, 24 Oct 2013 22:02:14 -0700
} Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
} > } 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.
} 
} There's a wider problem of what happens inside nested control
} structures, in particular functions.  Consider what happens when you use
} "pipestatus" inside a function, and then try to apply it to a pipeline,
} that happens to run that function at the right hand end, after the whole
} pipeline has finished.

You mean like this?

% true | false | true | (){ false | true | false; print $pipestatus }; print $pipestatus
1 0 1
0 1 0 0

Here's a loop construct:

% false | true | false | while true | false | true; do print $pipestatus; break; done; print $pipestatus
0 1 0
1 0 1 0

If that's not what you mean, then I'm not sure what is expected here.

} Logically, at least, this requires some kind of
} hierarchical handling of jobs, not processes --- although simply saving
} and restoring the current job might be good enough.  Does the current
} system take account of this kind of thing properly?

After 31879+31885, pipestats isn't assigned until the Job object is
deleted (which only happens after all parts of the job are finished)
*except* in one case: the job was suspended.  I'm pretty sure there is
still a race condition in that circumstance wherein the parent shell
may decide the current-shell task is done because a component process
hasn't yet received the signal.

Anyway, the point is that if the outer pipeline doesn't assign pipestats
until the current-shell construct at the tail has completed, then it's
theoretically safe to use $pipstatus for pipelines inside that construct.

} If so, maybe things are better than I thought.

One thing I still don't understand about this is the exactly when the
STAT_SUPERJOB flag is applied and whether that's going to affect some
case that we haven't yet thought to test.  There's a huge comment in
exec.c that attempts to explain it, but ...

There's a complication in that exec.c also says --

                        /* If this job has finished, we leave it as a
                         * normal (non-super-) job. */

-- which I'm afraid might complicate the handling of pipestats in a way
we're not expecting.  This is all probably related to the race condition
that I just mentioned, and indeed the big comment ends with:

 * The code for all this is distributed over three files (exec.c, jobs.c,
 * and signals.c) and none of them is a simple one. So, all in all, there
 * may still be bugs, but considering the complexity (with race conditions,
 * signal handling, and all that), this should probably be expected.