Re: "wait" loses signals

[Daniel Colascione]

> There are lots of programming languages around, they each have their
> particular
> niche - the reason their inventors created them in the first place.  Use
> an
> appropriate one, rather than attempting to shoehorn some feature that is
> needed
> into a language that was never intended for it - just because you happen
> to
> be a big fan of that language.   Spread your wings, learn a new one

That is a poor excuse for not fixing bugs. Maybe you can torture the
standards into confessing that this behavior isn't a bug. This behavior
nevertheless surprises people and nevertheless precludes various things
people want to do with a shell. Don't you think it's better that programs
work reliably than that they don't? Of course something working
intuitively 99.9% of the time and hanging 0.1% of the time is a bug. It's
not appropriate to treat that 0.1% hang as some kind of cosmic punishment
for using shell in a manner you find inappropriate: remember when we
believed in mechanism, not policy? Nor is the presence of the bug in other
shells adequate justification for leaving this one in a bad state. I've
never understood the philosophy of people who want to leave bugs unfixed.

No, it's not that much trouble to fix the bug. The techniques for fixing
this kind of signal race are well-known. In particular, instead of
waitpid, you use a self-pipe and signal the pipe in the signal handler,
and you have a signal handler for SIGCHLD. If we had a pwaitpid (like
pselect) we could use that too. If I could get Chet to look at my patches,
I'd fix it myself.