From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <53efcb3de52d8327fb42f54b6a5a1c08@felloff.net> Date: Wed, 3 Feb 2016 02:25:39 +0100 From: cinap_lenrek@felloff.net To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Fwd: lib9p: Add clunk callback to Srv struct Topicbox-Message-UUID: 820a5640-ead9-11e9-9d60-3106f5b1d025 > 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