Hi Ken, Hi Takashi, On Aug 30 19:00, Corinna Vinschen wrote: > Ok, let's discuss this. I added more code to my testcase and here's > what I see. I dropped all data from the output which doesn't change. > [...] > - InboundQuota and OutboundQuota are always constant values and > do not depend on the side the information has been queried on. > That certainly makes sense. > > - WriteQuotaAvailable does not depend on the OutboundQuota, but on > the InboundQuota, and very likely on the InboundQuota of the read > side. The OutboundQuota *probably* only makes sense when using > named pipes with remote clients, which we never do anyway. > > The preceeding output shows that ReadDataAvailable on the read side and > WriteQuotaAvailable on the write side are connected. If we write 20 > bytes, ReadDataAvailable is incremented by 20 and WriteQuotaAvailable is > decremented by 20. > > So: write.WriteQuotaAvailable == InboundQuota - read.ReadDataAvailable. > > Except when a ReadFile is pending on the read side. It's as if the > running ReadFile already reserved write quota. So the write side > WriteQuotaAvailable is the number of bytes we can write without blocking, > after all pending ReadFiles have been satisfied. > > Unfortunately that doesn't really make sense when looked at it from the > user space. > > What that means in the first place is that WriteQuotaAvailable on the > write side is unreliable. What we really need is InboundQuota - > read.ReadDataAvailable. The problem with that is that the write side > usually has no access to the read side of the pipe. > > Long story short, I have no idea how to fix that ATM. Well, what about keeping a duplicate of the read side handle on the write side just for calling NtQueryInformationFile? Attached is an untested patch, can you have a look if that makes sense? Btw., I think I found a bug in the new fhandler_pipe::create. If the function fails to create the write side fhandler, it deletes the read side fhandler, but neglects to close the read handle. My patch fixes that. While looking into this I found a problem in fhandler_disk_file in terms of handle inheritance of the special handle for pread/pwrite. I already force pushed this onto topic/pipe. Thanks, Corinna