Comment 8 for bug 387216

On Mon, 2009-06-15 at 15:48 +0000, Alex Nekrasov wrote:

> as far as I understand job_child_reaper() fix addresses the respawn
> problem only. There's a general problem of advancing job state beyond
> POST_START when post-start is still running, etc. As far as I could
> tell, the idea is to remain in PRE/POST_START or PRE/POST_STOP until
> those processes have finished, since we don't kill them. Is that so?
>
That's absolutely correct, yes.

> job_child_reaper() is one place where job state is advanced. The other
> is job_handle_event_finished().
>
job_handle_event_finished can only be called if job->blocked matches the
event being handled.

job->blocked will only be non-NULL if the job is in one of the blocking
states, that is JOB_STARTING and JOB_STOPPING.

Since the only thing that will advance the state beyond these, when
job->blocked has been set, is job_event_handle_finished() which resets
job->blocked back to NULL again, I'm not sure that you're correct.

Could you provide a test case?

Pure code review:

job.c:970-974 job->blocked should never be non-NULL in the JOB_WAITING
state, this seems unnecessary.

job.c:1044-1048,1063-1067,1072-1080,1099-1108 I tried to avoid such
logic in this code. In particular, the assertion that we should stop if
there's no main process is wrong. It's better to not try and change the
state at all.

job.c:1751-1757 this can never be reached, the case asserts that the
job state is only JOB_POST_STOP, so checking for a different value is
meaningless

Scott
--
Scott James Remnant
<email address hidden>