bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "wait" loses signals


From: Daniel Colascione
Subject: Re: "wait" loses signals
Date: Mon, 24 Feb 2020 06:44:12 -0800
User-agent: SquirrelMail/1.4.23 [SVN]

>     Date:        Mon, 24 Feb 2020 04:58:31 -0800
>     From:        "Daniel Colascione" <dancol@dancol.org>
>     Message-ID:  <07d1441d41280e6f95352222048d6485.squirrel@dancol.org>
>
>   | That is a poor excuse for not fixing bugs.
>
> Only if they are bugs.

That executing traps except in case you lose one rare race is painfully
obvious.

>
>   | Maybe you can torture the standards into confessing that this
>   | behavior isn't a bug.
>
> No torture required.  Once again, the standard documents the way users
> can expect shells to behave.

I refuse to let the standard cap the quality of a shell's implementation.
Missing signals this way is pure negative. It doesn't add to any
capability or help any user. It can only make computing unreliable and
hurt real users trying to automate things with shell.

> That is what a standard is - a common set
> of agreed operations

A standard is a bare minimum.

> attempt to get shells to change this way of
> working, and if you can get a suitable set to agree, and implement
> something
> new, that more meets your needs, then perhaps that might one day become
> the
> standard,

This opposition to doing more than the bare minimum that the standard
requires makes this task all the much harder.

>   | This behavior nevertheless surprises people
>
> Lots of things surprise people.

Sometimes people deserve to be surprised. This isn't one of those times.

>   | and nevertheless precludes various things
>   | people want to do with a shell.
>
> That was my point, that you just labelled a poor excuse.   Not everything
> is suitable for implementation in sh.   Sometimes you simply have to go
> elsewhere.

Making people go elsewhere *on purpose* by refusing to fix bugs is not
good software engineering.

> Wanting to do it in shell doesn't make it reasonable or
> possible.

It is reasonable and possible. All that's needed is to make an existing
operation that's almost perfectly reliable in fact perfectly reliable, and
as I've mentioned, it's not that hard.

> I want the shell to feed my dog, where is the dogfood option?

We're talking about fixing an existing shell feature, not adding a new one.

>   | Don't you think it's better that programs
>   | work reliably than that they don't?
>
> Yes, when they are written correctly.

By fixing this bug, we make a class of programs correct automatically.

>
>   | Of course something working intuitively 99.9% of the time and
>   | hanging 0.1% of the time is a bug.
>
> Nonsense.   An alternative explanation is that your intuition is wrong,
> and that it often works that way is just by chance.

We're talking about a documented feature that users expect to work a
certain way and that almost always *does* work that way and that diverges
from this behavior only under rare circumstances. Not the same as spacebar
heating.

> The program is
> broken because it is making unjustified assumptions about how things are
> specified to work.

This moralistic outlook is not helpful. It doesn't *matter* whether a
program is right or wrong or making unjustified assumptions or not.
Punishing programs does not make the world does not make the world better.
When a piece of infrastructure can transform these programs from incorrect
to correct at next to zero cost, it behooves that infrastructure component
to do that.

> This is the kind of common error that people who
> program (in any language) by guesswork often make "I saw Fred did this,
> and I tried it, and it worked for me like I thought it would, so it
> must do this similar thing like I think it will too".   Rubbish.

Ever hear of the "pit of success"? It's the idea that software gets better
when you make the intuitive thing happen to be the correct thing. Why
should we require a degree of cleverness greater than what a domain
requires? Why *not* make it so that, to the greatest extent possible,
shouldn't we let "I saw Fred do this" lead people to good patterns? Like I
said before, making things difficult on purpose doesn't actually achieve
anything.

[1] https://docs.microsoft.com/en-us/archive/blogs/brada/the-pit-of-success

>
>   | I've never understood the philosophy of people who want to leave
>   | bugs unfixed.
>
> Nor have I, except sometimes perhaps when it comes to costs.   But the
> issue here is whether this is a bug.  Your belief that it is does not make
> it so.

Your belief that this behavior is acceptable doesn't make it so --- except
under a pointlessly literal interpretation of the standards.

>   | No, it's not that much trouble to fix the bug.
>
> It isn't, if it needs fixing - but any fix for this will slow the shell
> (for what that matters, but some people care).  Further there are simpler
> cheaper techniques than the one described.

The fix for this issue will not meaningfully affect the speed of the
shell. Instead of waiting on waitpid directly, we wait on a pipe. Plenty
of programs do this already. Micro-optimizing for system call count will
hardly slow the shell: other factors matter a lot more, e.g., process
creation speed and command interpretation.

> work on a different shell) to make use
> of something like that it would need to be implemented in quite a lot
> of systems, including the commercial ones, which tend to be very
> conservative
> about adding new features for fun.

No, it wouldn't have to be implemented everywhere in order to use it
anywhere. AC_CHECK_FUNC exists.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]