Re: scp stalls on uploading in cygwin 3.5 current master.

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

On Aug 24 12:31, Takashi Yano via Cygwin wrote:
> On Thu, 24 Aug 2023 06:05:02 +0900
> Takashi Yano wrote:
> > Hi Corinna,
> > 
> > After the commit dedbbd74d0a8, "scp file server:." stalls.
> > I confirmed this when the "server" is a Linux machine.
> > The problem does not occur if it is reverted.
> > 
> > Could you please have a look?
> > 
> > commit dedbbd74d0a8f3b7dfae6188321703a47bb8a2b3
> > Author: Corinna Vinschen <corinna@vinschen.de>
> > Date:   Tue Aug 1 14:22:55 2023 +0200
> > 
> >     Cygwin: select: workaround FD_WRITE network event handling
> >     
> >     The FD_WRITE event is a false friend.  It indicates ready to write
> >     even if the next send fails with WSAEWOULDBLOCK.  *After* the fact,
> >     FD_WRITE will be cleared until sending is again possible, but that
> >     is too late for a select/write loop.
> >     
> >     Workaround that by using the WinSock select function when peeking
> >     at a socket and FD_WRITE gets indicated. WinSock select fortunately
> >     indicates writability correctly.
> >     
> >     Fixes: 70e476d27be8 ("(peek_socket): Use event handling for peeking socket.")
> >     Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
> 
> I'm not sure why at all, however, the following patch seems to
> solve the issue.
> 
> diff --git a/winsup/cygwin/select.cc b/winsup/cygwin/select.cc
> index 7b9473849..de5794c9f 100644
> --- a/winsup/cygwin/select.cc
> +++ b/winsup/cygwin/select.cc
> @@ -1790,7 +1790,7 @@ peek_socket (select_record *me, bool)
>        if (events & FD_WRITE)
>  	{
>  	  wfd_set w = { 1, { fh->get_socket () } };
> -	  TIMEVAL t = { 0 };
> +	  TIMEVAL t = { .tv_sec = 0, .tv_usec = 1 };
>  
>  	  if (_win32_select (0, NULL, &w, NULL, &t) == 0)
>  	    events &= ~FD_WRITE;

Yeah, this is weird. A TIMEVAL value of 0 indicates non-blocking,
so why should waiting a usec make that better?  It also potentially
slows down Cygwin's select noticably if multiple sockets are part
of the descriptor set.

Hmmm.

Is it possible that _win32_select returns with SOCKET_ERROR for 
some reason?

Unfortunately I'm a bit swamped ATM, but rather than setting t to 1
usec, what if the check goes:

  if (_win32_select (0, NULL, &w, NULL, &t) != 1)

?


Thanks,
Corinna