On Tuesday, September 22, 2009, erik quanstrom <quans...@quanstro.net> wrote: > On Tue Sep 22 23:12:27 EDT 2009, r...@swtch.com wrote: >> The extra tracking that has been proposed is unnecessary, >> and waiting for the Rflush doesn't make sense. The assumption >> is that the Rflush isn't ever going to arrive, because the connection >> is dead. > > what do you mean by "dead"? i/o to the same channel works > fine.
I mean that the code as written is assuming that if a read or write errors out, it can only happen for one of two reasons: 1) there was an interrupt note, in which case strcmp(error, Eintr) == 0 2) there has been an error on the 9P connection, in which case strcmp(error, Eintr) != 0 and the connection will never work again. My suggestion is to enforce #2: if a non-interrupt error happens, mark the connection so that the kernel won't even try to use it again. Separately, you might investigate what error is happening that violates the assumption above. In 9vx, it is easy: case #1 happened but the error was spelled wrong. Russ
