[9fans] tree problem - Plan9

This is a discussion on [9fans] tree problem - Plan9 ; 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 ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: [9fans] tree problem

  1. [9fans] tree problem

    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

  2. Re: [9fans] tree problem

    > 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


  3. Re: [9fans] tree problem

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

  4. Re: [9fans] tree problem

    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

  5. Re: [9fans] tree problem

    > 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


  6. Re: [9fans] tree problem

    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

  7. Re: [9fans] tree problem

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


  8. Re: [9fans] tree problem

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


  9. Re: [9fans] tree problem

    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.


  10. Re: [9fans] tree problem

    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

+ Reply to Thread