9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: cinap_lenrek@felloff.net
To: 9fans@9fans.net
Subject: Re: [9fans] Fwd: lib9p: Add clunk callback to Srv struct
Date: Wed,  3 Feb 2016 02:25:39 +0100	[thread overview]
Message-ID: <53efcb3de52d8327fb42f54b6a5a1c08@felloff.net> (raw)
In-Reply-To: <CAEDK68bnT6_Uk1yDifYxp43v8scshOkrqJPbLR9rscM66k0T6Q@mail.gmail.com>


> I'm using a file server for exchange data between 9P clients. When a new
> file is created, I create a plan9 channel and two threads (one for handle
> reads and other for writes), a write(2) to the file is translated into a
> sendp and a read(2) is translated into a recvp on the channel. The channel
> could be buffered or not, and then I want to maintain data allocated (aux
> related data) anyway, because the file server is a queueing system when
> channel have a buffer bigger than zero.

It is hard to say without seeing the code, but this construction sounds wrong
as recvp() in Srv.read would block the 9p read loop causing you to
not process any other 9p requests when one client is blocked in a read.
You also want to handle flushes otherwise you cannot interrupt/cancel
the blocked read. You can handle this by chaining the Req's that you
cannot satisfy immidiately in a linked list and respond to them from some
other proc or thread once you have data the client could read.

What do you mean by client? You could have multiple Srv's with each
client having its own network connection to it. Or it could mean multiple
attaches (mounts) and a single Srv. Or you it could mean you mean *someone*
reading the file and the state about a "Client" is in the Fid. Anyway,
it sounds like the problem you'r having with destroyfid() is that it doenst
give you access to information whoever is the client of the file closed no?

--
cinap



  parent reply	other threads:[~2016-02-03  1:25 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAEDK68Ze=Di=8qQt1GOfkhq9nxb29=q=Z+AUuxzJouOT6_WeTg@mail.gmail.com>
2016-02-01 21:54 ` Tiago Natel
2016-02-01 22:03   ` cinap_lenrek
2016-02-02 18:17     ` Tiago Natel
2016-02-02 19:15       ` Skip Tavakkolian
2016-02-03  1:25       ` cinap_lenrek [this message]
2016-02-03 11:53         ` Tiago Natel
2016-02-01 22:42   ` Skip Tavakkolian

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53efcb3de52d8327fb42f54b6a5a1c08@felloff.net \
    --to=cinap_lenrek@felloff.net \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).