Bullshit. It happens all the time. Rio+Plumber is a simple example. brucee
On 1/4/06, Russ Cox <[EMAIL PROTECTED]> wrote: > > 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 >
