Zsh Mailing List Archive
Messages sorted by:
Re: Waiting for a process without using pid
- X-seq: zsh-users 15415
- From: Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>
- To: zsh-users@xxxxxxx
- Subject: Re: Waiting for a process without using pid
- Date: Mon, 20 Sep 2010 07:55:21 -0700
- In-reply-to: <AANLkTimY1T1n9Nq7ePkNdSbJ9zhPobwzwM5SfNYb8qfB@xxxxxxxxxxxxxx>
- List-help: <mailto:email@example.com>
- List-id: Zsh Users List <zsh-users.zsh.org>
- List-post: <mailto:firstname.lastname@example.org>
- Mailing-list: contact zsh-users-help@xxxxxxx; run by ezmlm
- References: <AANLkTinyDC-OoGBzuisMKUg+OqeeqG=HKZrNDuJZL+sD@xxxxxxxxxxxxxx> <100916072654.ZM29712@xxxxxxxxxxxxxxxxxxxxxx> <4C950347.9060109@xxxxxxxxx> <100918124147.ZM31152@xxxxxxxxxxxxxxxxxxxxxx> <AANLkTimY1T1n9Nq7ePkNdSbJ9zhPobwzwM5SfNYb8qfB@xxxxxxxxxxxxxx>
On Sep 20, 1:09pm, Anonymous bin ich wrote:
} Ok, I have made some modifications, and I am now confused :(
} Three output are given here. Is there a race condition somewhere?
"setopt HUP" means that zsh starts the children with SIGHUP unblocked.
/bin/sh doesn't reset that signal, so when you "kill -HUP -$$" in the
parent, every process in the process group gets SIGHUP.
Because you used "sleep $1 & wait" in the child, the sleep process is
a separate entity which is also in the process group, so it is also
a target for that HUP. The race is whether the OS delivers the HUP
to child.sh before it delivers it to sleep (or, more likely, whether
child.sh gets a timeslice to run before sleep does); if child.sh goes
first, it can "kill $pid" before sleep has exited, otherwise it gets
an error because sleep already died on HUP.
You could probably observe this by putting a trap on CHLD in child.sh.
} PS: My original aim was to have both childs killed whenever SIGCHLD is
} received, and parent should continue to run. But I think I can manage
} that if this problem goes away...
Perhaps I was trying to make my solution too general; i.e., I didn't
want to care how many children were started or whether their PIDs had
been remembered. But if you always have exactly two children, why not
coproc read -E
trap "print -p" CHLD
kill $pid1 >&/dev/null
kill $pid2 >&/dev/null
Does it matter whether you kill again a PID that's already exited? If
PIDs recycle rapidly and this script is running as root, it might, but
otherwise I wouldn't think so.
Messages sorted by: