Re: bin/48875 (possible ash backgrounding bug)

[kre%NetBSD.org@localhost]

Synopsis: possible ash backgrounding bug

Responsible-Changed-From-To: bin-bug-people->krre
Responsible-Changed-By: kre%NetBSD.org@localhost
Responsible-Changed-When: Fri, 06 May 2016 19:52:54 +0000
Responsible-Changed-Why:
I am investigating this PR & the unnderlying issues.


State-Changed-From-To: open->analyzed
State-Changed-By: kre%NetBSD.org@localhost
State-Changed-When: Fri, 06 May 2016 19:52:54 +0000
State-Changed-Why:
This turns out not to be a backgrounding problem, but a redirection issue.
Since functions execute in the current shell, when a function is called
with fd redirections, the old values of the fds need to be saved (via dup)
so they can be restored after the function returns.  The careful closing of
stdout when running "f" in the supplied script, with the intent of this
not having it open while sleep is running (which works just fine when sleep
is called directly) is thus thwarted, the shell running the function has its
extra copy which remains open.

This, in the parent shell, reading the results of the command substitution
stalls until that fd is closed, which only happens after the function has
completed, after the sleep returns.
 
Most ways of trying to avoid this in the script do not work, however
it can be written as:
        echo $( { exec >&- ; f ;} & echo $! )
which closes the toublesome fd in the shell that will run the function,
before the function starts, leaving nothing to cause the stall.

I am still investigating just how the shell can figure this out on its
own, as one of the posix goals/requirements is that there is not supposed
to be any (trivial) way to determine if a utility is implemented as a command
or a function, and this would be a trivial way...