2016-02-02 23:25 GMT-02:00 <cinap_lenrek@felloff.net>:

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.

Source code: hg clone https://bitbucket.org/tiago4orion/dchan

Well, I'm doing a lot of tests with simultaneous access and everything 'appears' to works as expected.

I'm using threadlistensrv/threadpostmountsrv to handle each new 9P connection in a separate thread.

When a new client creates a file, the file server creates a Channel and two additional threads (one for block the reads, and one for block the writes) that will enqueue (reqqueuepush) the related requests. See here:

Create a new file (or dchan channel): fs.c:497,507

When someone attempts to write to this file: fs.c:/^fswrite

The request will be enqueued in the f->aux->wq (Reqqueue*) executing the function syncwrite on the writer thread of this file.

The fs.c:/^syncwrite will send the r->ifcall.data in the channel associated with the file (f->aux->chan) and it will block the writer thread (of this specific file) until someother 9P client attempts to read the file. The read is similar, but happens in the syncread function.

That way I'm able to create multiple clients:

plan9:

cpu% mount -c /srv/dchan /n/dchan

Linux:

# mount -t 9p -o port=6666 ip.of.dchan /n/dchan

# cd /n/dchan

# touch pipeline

The command above will create two associated with this specific file.

# cat pipeline

The command above will block in the recvp call in the reader thread of this file, until someone writes something in it.

cpu% cd /n/dchan

cpu% ls

ctl stats pipeline

cpu% echo AAAAAAAAAAAAA >> pipeline

The command above will issue a sendp in the same channel on the writer thread. The linux box will receive (recvp) the data and block in the next read(2).

That's the workflow.

What do you mean by client?

By client I mean a 9P connection: mount -c /srv/dchan /n/dchan

You could have multiple Srv's with each
client having its own network connection to it.

I'm using thread*srv function to achieve this. It's correct, isn't?

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?

Yes, I don't know if I understodd what you mean, but yeah, I need the information when someone closed the file (stopped reading the Channel).

Thanks

--
cinap