On Sun, Sep 5, 2010 at 4:42 PM, Harald Becker <[email protected]> wrote: >> See? fd 63 in the child LEAKS. > No! It doesn't leak. File descriptors could never leak on a fully > functional kernel/process management. File descriptors get always > closed, as soon as the process terminates.
Yes. As soon as process terminates. That's the problem: what if process *does not yet terminate*, but wants to close a descriptor which it obtained via open(FILENAME_FROM_<(cmd)_CONSTRUCT)? As I demonstrated, close(fd) will close only one of the TWO open desctriptors. Program does not know it has another fd, which is still open! >> Child doesn't realize it has it open. > True. That's the way this feature works in bash. > >> If child will decide to close the "file" it opened, >> fd 63 will still be open, and the reading process will not see the EOF! > True. This is exactly what happens at this point. The reading process > waits until the writing end of the pipe gets closed, which is at > termination of the child process. That is the way it will never leak. As > soon, as the child process terminates the reading end of the process > sees the EOF and continues it's work. > >> The second read() in the parent will not return 0 (EOF) at once, >> it will wait 3 seconds for child to exit. >> >> This is wrong. > > What's wrong with this? The wrong thing is that it waits for three seconds. In this construct: producer | consumer when producer closes its stdout, consumer will see EOF at once when it reads its stdin, even if producer does not terminate. In consumer <<(producer) construct, this is not the case. Not because it is documented to work that way, but only because of the implementation. For example, alternate implementation with named pipes in e.g. /tmp will not have this peculiarity (but will have other problems). -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
