scp stalls on uploading in cygwin 3.5 current master.
Fri Aug 25 19:29:24 GMT 2023
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
> 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
@@ -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);
for (int i = 0; i < si->num_w4; i += MAXIMUM_WAIT_OBJECTS)
switch (WaitForMultipleObjects (MIN (si->num_w4 - i,
Takashi Yano <email@example.com>
More information about the Cygwin