Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: job-control
- X-seq: zsh-workers 9495
- From: "Bart Schaefer" <schaefer@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: PATCH: job-control
- Date: Mon, 31 Jan 2000 11:52:00 +0000
- In-reply-to: <200001311000.LAA29263@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <200001311000.LAA29263@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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
Messages sorted by:
Reverse Date,
Date,
Thread,
Author