Re: bin/48875 (possible ash backgrounding bug)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/48875; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: bin/48875 (possible ash backgrounding bug)
Date: Wed, 25 May 2016 22:37:56 +0700

     Date:        Wed, 25 May 2016 13:45:01 +0000 (UTC)
     From:        Edgar =?iso-8859-1?B?RnXf?= <ef%math.uni-bonn.de@localhost>
     Message-ID:  <20160525134501.615E27AAB0%mollari.NetBSD.org@localhost>
 
   |  > I think this is fixed as best it reasonably can be,
   |  > Do you agree?
   | I guess yes, but I'm somewhat overwhelmed by how complicated the
   | issue really is.
 
 Turns out that it is even more complicated... I have not yet considered
 the issue or traps (which Jilles Tjoelker, principal maintainer of the
 FreeBSD shell, pointed out to me recently.)   I am still pondering how
 best to deal with this.   It might mean that the method used for the
 current fix cannot work at all, and the whole thing needs to be revisited.
 
   | With your fix, the shell will mostly do what I mean (which is good),
   | but will it still do what some shell hackers who know about the
   | circumstances will expect it to do?
 
 Mostly I think, as it is, if only we could ignore traps.   But we cannot.
 
 It is all a bit messy as functions have to operate in the current shell,
 which means anything that is done which is supposed to be local to the
 function (such as redirecting its input or output) have to be able to be
 undone again.   The only way to do that is to keep fd's open, so they can
 be returned when needed.   That then has the side effect you have seen
 when something else is waiting on the fd being closed.
 
 The current fix attempts to determine when the fd cannot be needed again,
 and so can simply be closed, but as with all attempts to predict the future,
 it is never as easy as it seems it should be.
 
   |  Does POSIX (either the standard or the experts behind the standard)
   | say anything about the issue?
 
 The standard no - it does not say about implementation, nor about sequencing
 or timing.  The correct eventual outcome was achieved in the case you
 highlighted, everything else beyond that is just a matter of hoq the
 implementation works.   The experts, I don't know, I am not sure it has
 ever really been considered.
 
 kre