> The solution may, alternatively be to register a clunk()
> function and each can do what they want with it though I
> do not like it because I feel I should receive things related
> with files and not with fids.

the read and write requests you receive are for fids,
not files. you pull out the file using fid->file.

you can use destroyfid to find out when a fid is
completely clunked. from 9p(2):

Destroyfid
When a Fid's reference count drops to zero (i.e., it
has been clunked and there are no outstanding requests
referring to it), destroyfid is called to allow the
program to dispose of the fid->aux pointer.

you can get at the file by using fid->file.

russ

> > The solution may, alternatively be to register a clunk()
> > function and each can do what they want with it though I
> > do not like it because I feel I should receive things related
> > with files and not with fids.
>
> the read and write requests you receive are for fids,
> not files. you pull out the file using fid->file.
>
> you can use destroyfid to find out when a fid is
> completely clunked. from 9p(2):
>
> Destroyfid
> When a Fid's reference count drops to zero (i.e., it
> has been clunked and there are no outstanding requests
> referring to it), destroyfid is called to allow the
> program to dispose of the fid->aux pointer.
>
> you can get at the file by using fid->file.

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.

I needed to forward the clunk immediately, because
otherwise the user might not be able to reuse a fid
immediately after having clunked it (more accurately:
if the user would do so, and the 'other' file server
would not see the clunk before the reuse, there might
be trouble.)


Axel.

I'm sort of missing the point here. What was the case where destroyfid
was not sufficient? I don't understand the user reusing a fid if the
user had not stopped using it, i.e. if the user had two references to
the fid, and clunked it once, isn't reusing that fid an error of some
sort?

IIRC destroyfid is just what is called when the ref count is zero,
which is pretty close to what you want much of the time.

(that said, I keep thinking I want clunk in there anyway

thanks

ron

> 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

On 5/3/07, Russ Cox wrote:
>
> the read and write requests you receive are for fids,
> not files. you pull out the file using fid->file.
>

Then I want the clunk :-).

> you can use destroyfid to find out when a fid is
> completely clunked. from 9p(2)

I want each clunk, not the last one...


--
- curiosity sKilled the cat

>> you can use destroyfid to find out when a fid is
>> completely clunked. from 9p(2)
>
> I want each clunk, not the last one...

there is only one per fid, and you'll get it.

russ

> I want each clunk, not the last one...

there will be at most one clunk for an open
file, as it's illegal to clone an open fid.

in the usual case (when clients are being non-malicious)
destroyfid on an open file will be trigged
by that clunk.

it does seem a pity that there seems to
be no way of delaying the response to a clunk
without stopping the server read loop.

i think that for unusual servers, including filters, it's easier just to serve
the protocol, rather than try to second-guess an otherwise helpful library.

On 5/3/07, Russ Cox wrote:
> >> you can use destroyfid to find out when a fid is
> >> completely clunked. from 9p(2)
> >
> > I want each clunk, not the last one...
>

I meant I want to get the clunk inmediately not
after the last reference drop, sorry.


--
- curiosity sKilled the cat