Re: cygrunsrv + sshd + rsync = 20 times too slow -- throttled?

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On Aug 30 16:05, Corinna Vinschen wrote:
> On Aug 30 09:36, Ken Brown wrote:
> > BTW, when I was working on the pipe approach to AF_UNIX sockets
> > (topic/af_unix branch), I had occasion to step through
> > select.cc:pipe_data_available in gdb, and the use of fpli.OutboundQuota -
> > fpli.ReadDataAvailable definitely seemed wrong to me.  So when I wrote
> > peek_socket_unix on that branch, I used fpli.WriteQuotaAvailable, as Takashi
> > is suggesting now.
> 
> If that's working reliable these days (keeping fingers crossed for W7),
> it's ok if we use that.  We may want to check if the above observation
> in terms on WriteQuotaAvailable on a pipe with pending read is still an
> issue.

Ok, I wrote a small testcase.  It creates a named pipe, reads from the
pipe, then, later, writes to the pipe.  Interlaced with these calls, it
calls NtQueryInformationFile(FilePipeLocalInformation) on the write side
of the pipe.  Kind of like this:

  CreatePipe
  NtQueryInformationFile
  ReadFile
  NtQueryInformationFile
  WriteFile
  NtQueryInformationFile

Here's the result:

Before ReadFile:

  InboundQuota: 65536
  ReadDataAvailable: 0
  OutboundQuota: 65536
  WriteQuotaAvailable: 65536

While ReadFile is running:

  InboundQuota: 65536
  ReadDataAvailable: 0
  OutboundQuota: 65536
  WriteQuotaAvailable: 65494	!!!

After WriteFile and ReadFile succeeded:

  InboundQuota: 65536
  ReadDataAvailable: 0
  OutboundQuota: 65536
  WriteQuotaAvailable: 65536

That means, while a reader on the reader side is waiting for data, the
WriteQuotaAvailable on the write side is decremented by the amount of
data requested by the reader (42 bytes in my case), just as outlined in that
mail from 2004.  And this is on W10 now.

What to do with this information?  TBD.

Side note:  My testcase is starting a second thread to call ReadFile.
For that reason I was using synchronous IO on the pipe since, well,
never mind if that thread is blocked in ReadFile, right?  Nothing keeps
us from calling NtQueryInformationFile on the write side of the pipe,
right?

Wrong.  While the second thread was blocked in ReadFile, the call to
NtQueryInformationFile was blocking, too :-P

I had to convert the read side of the pipe to asynchronous mode to be
able to call NtQueryInformationFile(FilePipeLocalInformation) on the
write side of the pipe, while the read side is performing a ReadFile
operation.


Corinna