From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dmta0020.nifty.com (mta-snd00004.nifty.com [106.153.226.36]) by sourceware.org (Postfix) with ESMTPS id 18F663858C62 for ; Fri, 25 Aug 2023 19:29:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 18F663858C62 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 dmta0020.nifty.com with ESMTP id <20230825192924310.KPXM.110240.HP-Z230@nifty.com> for ; Sat, 26 Aug 2023 04:29:24 +0900 Date: Sat, 26 Aug 2023 04:29:24 +0900 From: Takashi Yano To: cygwin@cygwin.com Subject: Re: scp stalls on uploading in cygwin 3.5 current master. Message-Id: <20230826042924.53b49a9f8372a9196a151425@nifty.ne.jp> In-Reply-To: References: <20230824060502.c4798062cb19d4d35a5633ae@nifty.ne.jp> <20230824123131.390b4471915c963425c77608@nifty.ne.jp> <20230825174832.9ebae8112667d5d5411cb8db@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=-12.0 required=5.0 tests=BAYES_00,GIT_PATCH_0,KAM_DMARC_STATUS,NICE_REPLY_A,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: Hi Corinna, On Fri, 25 Aug 2023 12:50:56 +0200 Corinna Vinschen wrote: > On Aug 25 17:48, Takashi Yano via Cygwin wrote: > > 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? Your idea seems to work. The following patch looks to solve the issue. Is it supposed to be any side effect()? diff --git a/winsup/cygwin/select.cc b/winsup/cygwin/select.cc index 7b9473849..443f95e68 100644 --- a/winsup/cygwin/select.cc +++ b/winsup/cygwin/select.cc @@ -1824,8 +1824,16 @@ thread_socket (void *arg) { for (select_record *s = si->start; (s = s->next); ) if (s->startup == start_thread_socket) - if (peek_socket (s, false)) - event = true; + { + if (peek_socket (s, false)) + event = true; + else if (s->write_selected) + { + /* Retrigger WSA socket event */ + fhandler_socket_wsock *fh = (fhandler_socket_wsock *) s->fh; + fh->write ("", 0); + } + } if (!event) for (int i = 0; i < si->num_w4; i += MAXIMUM_WAIT_OBJECTS) switch (WaitForMultipleObjects (MIN (si->num_w4 - i, -- Takashi Yano