[9fans] tree problem

[9fans] tree problem

[Gorka Guardiola]

I was using a tree created by alloctree(), 9pfile(2) to write a
synthetic filesystem and got
into a problem I have seen before, but I can´t remember if I asked
about it here (google
doesn't find anything).

There is no way to register a close() function in Srv which can be
called when a clunk
is received for an open file.

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.

This is important to do garbage collection in some
cases (for example if you open something when you get an open and want to
close it). Is there a reason for this function not existing? am I
missing something?.

At some point in the past I had a modified version of the library (my
proposed solution)
and at another I played with the references (very ugly) if my memory
serves right.
-- 
- curiosity sKilled the cat

Re: [9fans] tree problem

[Russ Cox]

> 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

Re: [9fans] tree problem

[Axel Belinfante]

> > 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.

Re: [9fans] tree problem

[ron minnich]

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

Re: [9fans] tree problem

[Russ Cox]

> 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

Re: [9fans] tree problem

[Gorka Guardiola]

On 5/3/07, Russ Cox <rsc@swtch.com> 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

Re: [9fans] tree problem

[Russ Cox]

>> 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

Re: [9fans] tree problem

[Gorka Guardiola]

On 5/3/07, Russ Cox <rsc@swtch.com> 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

Re: [9fans] tree problem

[rog]

> 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.

Re: [9fans] tree problem

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 157 bytes --]

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.

[-- Attachment #2: Type: message/rfc822, Size: 2485 bytes --]

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] tree problem
Date: Thu, 3 May 2007 18:30:19 +0100
Message-ID: <b8c6c51342c73bbb63ec0d0f766fd6a3@vitanuova.com>

> 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.