From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Subject: Re: [9fans] tree problem From: "Russ Cox" Date: Thu, 3 May 2007 11:55:37 -0400 In-Reply-To: <200705031528.l43FSQ006268@zamenhof.cs.utwente.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Message-Id: <20070503155539.077301E8C1F@holo.morphisms.net> Topicbox-Message-UUID: 5734ee28-ead2-11e9-9d60-3106f5b1d025 > at a time I had modified my local lib9p to be able > to register a clunk function. > > I needed it for a 'filterfs' that sits between a user > and another file server. > it forwarded each incoming request (potentially modified) > to the other file server, and handed back its responses > (potentially modified) to the user. > the forwarded requests contained the fids as given by the user. an alternate solution would have been to use your own fid space, though that's not as convenient. destroyfid != clunk because i was worried about buggy or malicious clients that might clunk a fid while there were still pending requests using that fid. for example issue a Tread and then Tclunk the fid before the Rread comes back. then the Tclunk handler can't free associated data structures because the Tread handler might still be using them. i suppose i could have still had a clunk handler and just delayed processing Tclunk until any pending ops on that fid finished. russ