From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 22 Sep 2009 20:11:19 -0700 Message-ID: Subject: Re: [9fans] 9vx (is this the right list)? import issue From: Russ Cox To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Topicbox-Message-UUID: 7610eb00-ead5-11e9-9d60-3106f5b1d025 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. The problem is here: void mountio(Mnt *m, Mntrpc *r) { int n; while(waserror()) { if(m->rip == up) mntgate(m); if(strcmp(up->errstr, Eintr) != 0){ mntflushfree(m, r); <<<< nexterror(); } r = mntflushalloc(r, m->msize); } The implicit assumption is that if reading from the mounted connection gets any error other than Eintr, the connection is dead and will never receive another message. The call to mntflushfree cleanly tears down the messages this proc is waiting for by behaving as if the flush responses had come back in. In 9vx, the problem is that the errstr is "Interrupted system call" (the Unix string for errno EINTR) instead of Eintr == "interrupted". The fix is to correct whatever has translated EINTR to "Interrupted system call" to use the correct string. Drawterm probably has the same issue and the same fix. There are fewer interrupts flying around in drawterm. The kernel may even have the same issue, if a mounted connection can get an error (other than "interrupted") out of read or write but then work at the next call. A way to avoid this problem in the future is to mark the mnt (m) as dead, so that no other procs will try to read from the connection and get confused. Russ