Re: When a hashed pathname is deleted, search PATH

[Linda Walsh]

Chris Down wrote:
> Linda Walsh writes:
> > If this was a reactor control program, that's one thing, but in
> > deciding what solution to implement to save some small lookup time or
> > throw it away, an 90% solution is probably fine.  It's called a
> > heuristic.  AI machines use them.  Thinking people use them.  Why
> > should bash be different?
>
> You don't use heuristics when you have access to the underlying
> mechanisms, that's an extremely poor way to program, and an extremely
> good way to accrue technical debt.
----
Depends on how you implement it.  If you have your check existence
routine separated, then if you need to implement a different
method of calling it in the future, you get code reuse.

No technical debt has been created, though you would have tried
a solution that wasn't satisfactory and needs to be replaced.
But it was a solution that didn't exist, so no debt would
exist from the initial state, to the contrary, extra check
for existence routines might already have been created.

> > As you drive up the 'perfection rate' or 'uptime' to another 9 (i.e. 90%
> > to 99, or 99 to 99.9%) the costs usually go up exponentially.
> > If it costs 1 day to implement an 90% algorithm, a 99% algorithm
> > easily be a 1-3 month project depending on how you measure.
> > 99.9 could could involve a year or more.
>
> If this has been your experience, then you have been working in
> environments which I would suggest are not representative of typical
> software development. 
----
        We are talking about limited time on the part of the developer(s).
If you want to submit a patch for a 100% proof case that doesn't
require having to recheck an already looked up path in the parent
for every child exec, I'm sure everyone would benefit.


> Proposing solutions based entirely upon speculation about the
> environments of the user base of a program that is shipped with almost
> all consumer/server Linux distributions is myopic.
----
        I didn't.  It seems that someone said that timing wouldn't
be an effective solution for systems that took >.1 (or whatever cutoff
would be used) seconds to do a single pathwalk.  My answer was that
if that system was going to take that long to do a single pathwalk & exec,
then rewalking PATH to look for a new exec (which would be further along
in the path than the previous one was), would take longer.

        If it takes that long to look up paths often enough to require
that the hashed path for an executable be walked by the parent
before letting the child walk it, you want to incur that for all
linux systems -- both consumer/server distributions, then you are
it *isn't* myopic, it is a downgrade in performance for a case that
the user has created on their system and not issued a rehash for.

        The point is you are saying that bash must using "polling" each time
a file is executed to see if it exists, rather than being informed by
a child via an interrupt mechanism that there is a problem.

        Sure, you could forget the timing part -- and have bash check
for every child, it's reason for exiting and if ENOENT, then check
whatever path the child was just spawned with if you wanted a general
solution for a low-incident problem.  It would still be better than
having the parent "poll" each time to see if anything has changed.