Re: PATCH: job-control

["Bart Schaefer" <schaefer@candle.brasslantern.com>]

On Jan 31, 11:00am, Sven Wischnowsky wrote:
} Subject: Re: PATCH: job-control
}
} > Also, the child_block() call following the unblock in exec.c is redundant,
} > because block/unblock are not stacked and the first thing that waitjobs()
} > does [via waitjob()] is to call child_block().
} 
} Yes, I saw that at the weekend, too (I'm playing with a non-recursive
} execution code at home).
} 
}  		if (!(jn->stat & STAT_LOCKED)) {
}  		    child_unblock();
} -		    child_block();
}  		    waitjobs();
}  		}

Actually, I just realized that that's not right either.  It's not safe to
go on examining jn->stat and jobtab[list_pipe_job] etc. in the rest of
execpline() with child_unblock() in effect (it's left unblocked when
waitjobs() returns).

So we may end up removing the child_unblock() there, but I think we need
to block again after waitjobs().

Index: Src/exec.c
===================================================================
@@ -983,6 +983,7 @@
 		if (!(jn->stat & STAT_LOCKED)) {
 		    child_unblock();
 		    waitjobs();
+		    child_block();
 		}
 		if (list_pipe_child &&
 		    jn->stat & STAT_DONE &&

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com