From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 23 Sep 2009 00:56:59 -0400 To: 9fans@9fans.net Message-ID: In-Reply-To: <> References: <> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] 9vx (is this the right list)? import issue Topicbox-Message-UUID: 761d0f2a-ead5-11e9-9d60-3106f5b1d025 > 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. how sure are we that 1 holds? couldn't there be other, legitimate and transient errors? could a user-delivered note sneak in and confuse the issue? the problem with my solution is that it could leak tags. i don't see this as a significant problem, but i could be wrong. i think the connection would need to be pretty broken for tags to be leaked. marking connections dead also adds tracking, but in a new place. it could have trouble if ever a transient error happens when strcmp(error, Eintr) == 0, which can happen in 9vx or dt. - erik