> 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
