Re: Waiting for a process without using pid

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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
this?

    coproc read -E
    trap "print -p" CHLD

    ./child.sh &
    pid1=$!
    ./child.sh &
    pid2=$!

    read -p
    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.