From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <13426df10909221121g5d203f06qeabf4356940d1193@mail.gmail.com> References: <13426df10909211129n33481db3gb0ddf024cd67d90a@mail.gmail.com> <13426df10909221027u4279cd72hf7b651dfd120339b@mail.gmail.com> <13426df10909221121g5d203f06qeabf4356940d1193@mail.gmail.com> Date: Tue, 22 Sep 2009 19:35:19 +0100 Message-ID: From: roger peppe To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] 9vx (is this the right list)? import issue Topicbox-Message-UUID: 7552495c-ead5-11e9-9d60-3106f5b1d025 2009/9/22 ron minnich : > So, basically, the way I see it is, grep proc gets an interrupt, > kernel will try to flush RPCs which we initiated, we drop the (we > think) flushed rpc struct onto the rpcfree list, but the reply from > the server is still in flight. We reuse the rpc from rpcfree list, we > send out a new T, with the same tag as the previous one which we think > we flushed, we get the reply from the earlier RPC, tags match, R does > not match T, bad day. surely the correct way to go about this (caveat: i haven't looked at the code) is to drop the rpc struct onto the rpcfree list only when the Rflush is received? from experience with writing heavily used 9p services, getting flush properly right is a bitch.