gwyn@smoke.BRL.MIL (Doug Gwyn) (08/23/89)
The 4.3BSD rshd (normally in its child branch) unconditionally closes an FD named "f" in the source code without checking whether f = 0, 1, or 2. If inetd always starts the slave process with all three FDs open, this will work, but it seems an unsafe assumption. (Only FD 0 is documented as being set up by inetd.) There's no particular reason FD "f" shouldn't have been closed back where the dup2(f,*)s occur, being careful not to close(f) unless f > 2. By the way, to anyone who studies the rsh/rshd implementation, it should be apparent that it would be really useful to have a way to ask the kernel to "pump" data from one socket into another, instead of having to spawn a child process to do the pumping. With the kernel doing it, there would be far fewer context switches. Yours for improved plumbing...
karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) (08/23/89)
gwyn@smoke.brl.mil writes:
The 4.3BSD rshd (normally in its child branch) unconditionally
closes an FD named "f" in the source code without checking whether
f = 0, 1, or 2.
It doesn't have to do so. `f' is passed into doit() from main() as a
constant 0.
--Karlgwyn@smoke.BRL.MIL (Doug Gwyn) (08/25/89)
In article <KARL.89Aug23121144@triceratops.cis.ohio-state.edu> karl@triceratops.cis.ohio-state.edu (Karl Kleinpaste) writes: -gwyn@smoke.brl.mil writes: - The 4.3BSD rshd (normally in its child branch) unconditionally - closes an FD named "f" in the source code without checking whether - f = 0, 1, or 2. -It doesn't have to do so. `f' is passed into doit() from main() as a -constant 0. If it were, then the code would be horribly wrong!