Re: [9fans] clunk clunk

[Russ Cox <rsc@swtch.com>]

> When a process exits it closes it's fds, so it sends a
> Tclunk ...but if the process it sends it to is exiting it can't
> respond.   It's in the same position.  Call it "deadly embrace".
>
> Think about it.

This only happens if two file servers have mounted each other,
which creates many other possibilities for deadlock too.

Usually file servers are careful to dissociate from the name
spaces in which they mount themselves, so that they don't
access their own files and cause ref count problems.
This has the added effect that future servers that get mounted
into the name space don't end up mounted in the first server's
name space.  So these kind of loops basically don't happen.

What processes do you have running that are in this deadly
embrace?  Standard programs or ones you wrote?  If the
former, which ones?  Are you sure they're in Tclunk?

There is one exception in Plan 9: upas/fs and plumber have
each other mounted, so that plumber can send around
references to upas/fs's files.  It sometimes happens that
they end up sticking around just because of the circular
ref count, if somehow the session ends without a hangup
note being sent to the note group.  Even in this case, though,
the Tclunk thing doesn't happen, because plumber doesn't
keep any of upas/fs's files open.  It could possibly happen
if the plumber managed to get killed in the middle of walking
one of the upas paths during a stat, but that wouldn't happen
hundreds of times on a single system.

Instead of making us read through the Inferno code,
why not tell us what you did to fix it?  A separate kproc
to run all clunks?  Close all the non-devmnt chans first?

Russ