X-Recipient: archive-cygwin AT delorie DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E3FA03858418
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1692960673;
	bh=BYANfws6l5qnf2GgHKSJfX33EEmHP1D0dFYy9o9ltUo=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=UM+BvopYSL6+tskyHPe3YhkJCnvs29Vti0Yx6gXq1cF36LdNMM68AZF+N9N4d91qr
	 cDdWjTwRfbz9zxk5D0O9MkZrxYnWMAnpp08iQ6CZjqk+V1ofNRHfn3hxCaE9lVznnv
	 R5EKYTaqs+qdyonIc8iNE76j/KYA54/A/uXcylqE=
X-Original-To: cygwin AT cygwin DOT com
Delivered-To: cygwin AT cygwin DOT com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9FB923858C53
Date: Fri, 25 Aug 2023 12:50:56 +0200
To: cygwin AT cygwin DOT com
Subject: Re: scp stalls on uploading in cygwin 3.5 current master.
Message-ID: <ZOiHkCWY7PK3livD@calimero.vinschen.de>
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20230824060502 DOT c4798062cb19d4d35a5633ae AT nifty DOT ne DOT jp>
 <20230824123131 DOT 390b4471915c963425c77608 AT nifty DOT ne DOT jp>
 <ZOcb9SKtMPTQfj/m AT calimero DOT vinschen DOT de>
 <20230825174832 DOT 9ebae8112667d5d5411cb8db AT nifty DOT ne DOT jp>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <20230825174832.9ebae8112667d5d5411cb8db@nifty.ne.jp>
X-BeenThere: cygwin AT cygwin DOT com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From: Corinna Vinschen via Cygwin <cygwin AT cygwin DOT com>
Reply-To: cygwin AT cygwin DOT com
Cc: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie DOT com AT cygwin DOT com>

On Aug 25 17:48, Takashi Yano via Cygwin wrote:
> On Thu, 24 Aug 2023 10:59:33 +0200
> Corinna Vinschen wrote:
> > > 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)
> > 
> > ?
> 
> This did not help. I looked into this deeper and noticed that:
> 1) _win32_select() sometimes returns 0.
> 2) If _win32_select() returns 0, WaitForMultipleObjects(..., INFINITE)
>    is called in thread_socket().
> 3) WaitForMultipleObjects() sometimes does not return for FD_WRITE
>    for unknown reason.
> This causes the stall.

So the situation is that the network event handling returned FD_WRITE,
because it always returns FD_WRITE as long as a non-blocking send()
function didn't explicitely fail due to buffer overrun.

However, _win32_select will notice that the buffer is full, so it
does not return 1, but 0.  I e., the socket is not ready for writing.

Now you're saying that it's possible that the following WFMO will
never return?

That would mean that the FD_WRITE event won't be triggered again because
it already *had* been triggered and the only way to re-enable it is to
call one of the send() functions (see
https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-wsaeventselect)

I don't have an answer to this problem yet.

Can we use send(sock, "", 0) to reenable FD_WRITE, perhaps?


Corinna

-- 
Problem reports:      https://cygwin.com/problems.html
FAQ:                  https://cygwin.com/faq/
Documentation:        https://cygwin.com/docs.html
Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple