From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dmta1009.nifty.com (mta-snd01011.nifty.com [106.153.227.43]) by sourceware.org (Postfix) with ESMTPS id 2AB163858C53 for ; Fri, 25 Aug 2023 08:48:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2AB163858C53 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=nifty.ne.jp Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=nifty.ne.jp Received: from HP-Z230 by dmta1009.nifty.com with ESMTP id <20230825084832817.UEWU.19111.HP-Z230@nifty.com> for ; Fri, 25 Aug 2023 17:48:32 +0900 Date: Fri, 25 Aug 2023 17:48:32 +0900 From: Takashi Yano To: cygwin@cygwin.com Subject: Re: scp stalls on uploading in cygwin 3.5 current master. Message-Id: <20230825174832.9ebae8112667d5d5411cb8db@nifty.ne.jp> In-Reply-To: References: <20230824060502.c4798062cb19d4d35a5633ae@nifty.ne.jp> <20230824123131.390b4471915c963425c77608@nifty.ne.jp> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.30; i686-pc-mingw32) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-11.3 required=5.0 tests=BAYES_00,GIT_PATCH_0,KAM_DMARC_STATUS,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: 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. -- Takashi Yano