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

[Corinna Vinschen]

On Aug 30 10:52, Ken Brown wrote:
> On 8/30/2021 10:12 AM, Corinna Vinschen wrote:
> > On Aug 30 09:41, Ken Brown wrote:
> > > The approach I've taken on the topic/pipe branch is to stop using overlapped
> > > I/O and to always keep the blocking mode of the Windows pipe in sync with
> > > the blocking mode of the fhandler.  This seems to work pretty well so far,
> > > although problems could certainly show up after further testing.
> > 
> > Erm... afaics, fhandler_pipe::raw_read and fhandler_pipe::raw_write are
> > still using overlapped IO on blocking sockets.  Otherwise, how'd you
> > handle signals?
> > 
> > Just to be clear, Windows pipes can be read/write in three modes:
> > 
> > - non-blocking	 (FILE_PIPE_COMPLETE_OPERATION)
> > - synchronous	 (FILE_PIPE_QUEUE_OPERATION, non-overlapped)
> > - asynchronous   (FILE_PIPE_QUEUE_OPERATION, overlapped)
> 
> OK, I've been thoroughly confused about what "overlapped" means.  I thought
> it meant specifying FILE_FLAG_OVERLAPPED and a pointer to an OVERLAPPED
> structure, both of which (I thought) only made sense when using the Win32
> API rather than the NT API.
> 
> I *think* I understand what you mean now.  By using an event in the calls to
> NtReadFile and NtWriteFile in the blocking case, I'm selecting asynchronous
> mode, right?

Sorry, yes, OVERLAPPED is a Win32 expression only.  The NT calls only
differ between synchronous and asynchronous calls.  For asynchronous
calls you can either call a wait function on the file handle or you can
add an event object or a completion routine.

But that makes me wonder...  Looks like my idea to add the
FILE_SYNCHRONOUS_IO_NONALERT flag was a red herring.  This enforces
synchronous operation, which is not what we want.  Bummer.

However, if C# can't work with asynchronous handles, I wonder how to
fix this issue at all.


Corinna