No subject

[seanq@plan9.att.com seanq@plan9.att.com]

>That sounds like a bug.  But why doesn't ftpfs suffer the same
>symptoms?  On the other hand, even
>	sleep 10 >[0]/tmp/zz >[1]/tmp/zz >[2]/tmp/zz >[3]/tmp/zz &
>makes the window stick around; what files is that holding open?
>It should be none, right?

When you open a window, a new name space is created with the window's
files bound in the appropriate places, i.e. /dev and /mnt/8½.  These
binds are in effect open file descriptors and the window will not
go away until they are closed.  This is why the command line
	sleep 10 >[0]/tmp/zz >[1]/tmp/zz >[2]/tmp/zz >[3]/tmp/zz &
stops the window from closing.

The namespace itself is referenced counted, so when all processes associated
with the name space have exited, any open files bound in the namespace are closed.

The reason the window closes even though ftpfs is running is rather subtle.
When ftpfs is started, it rforks the server process with the flag RFNAMEG
set.  This puts the server process in a copy of the original namespace.
Note that since it is a copy of the original namespace, it contains
references the the window's files.
The server is accessed by a pipe that is mounted in the original namespace.
When /bin/rc exits, the original namespace closes.  At this point, the window
is held up by ftpfs's namespace.  However, the original name-space contains
the only reference to one end of the pipe to ftpfs, thus this end of
the pipe is closed.  Ftpfs notices this and dies.  This closes
the namespace associated with ftpfs, closing the files associated with the window,
which finally allows the window to close.......

The reason that the above does not occur for dossrv is that the server
process is not rforked with RFNAMEG set.  This is probably a bug.  The net
result is that rc and dossrv share the same namespace, and thus when rc exits,
the namespace is not closed and hence dossrv does not die.....In effect
dossrv holds itself up, which stops the window from closing.