From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <corinna@sourceware.org>
Received: by sourceware.org (Postfix, from userid 2155)
	id 10AB3385DC03; Thu, 24 Aug 2023 08:59:35 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 10AB3385DC03
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1692867575;
	bh=5gil/DvN7nOL9PF3CrAJXLB9CqJ2jl+kb1ggGaAZDFY=;
	h=Date:From:To:Subject:Reply-To:References:In-Reply-To:From;
	b=kJKFz4Ud5JbN5B/m59+rjdA25L1dQXHI8ZmYsPAlGdxdj1lZeI5c4oVn+3lL2/mzL
	 2vAbdLVLLNbe9B0y/vYA1XXpAaw0MmW+sGV3ZHMR5XB0yRcQLTCoc6aGMr3eKPab6P
	 IsUyOsamprWG0ja+LtL+EwWnM728GcCgbGqY9Hgk=
Received: by calimero.vinschen.de (Postfix, from userid 500)
	id 1936AA80C9F; Thu, 24 Aug 2023 10:59:33 +0200 (CEST)
Date: Thu, 24 Aug 2023 10:59:33 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: scp stalls on uploading in cygwin 3.5 current master.
Message-ID: <ZOcb9SKtMPTQfj/m@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <20230824060502.c4798062cb19d4d35a5633ae@nifty.ne.jp>
 <20230824123131.390b4471915c963425c77608@nifty.ne.jp>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20230824123131.390b4471915c963425c77608@nifty.ne.jp>
List-Id: <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