From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <corinna@sourceware.org>
Received: by sourceware.org (Postfix, from userid 2155)
	id F1F4C3858C53; Fri, 25 Aug 2023 12:23:17 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F1F4C3858C53
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1692966197;
	bh=13Rfp4EnFmdM5IFDEQpM7FMfmvk7Rn6+9cUg/4qb9fo=;
	h=Date:From:To:Subject:Reply-To:References:In-Reply-To:From;
	b=TY5w1fmHiv71+yMH+ss1PABp9oG6A5rI8WCZAIrDno0ro7C9ogc3xZqnadpCLWn0v
	 PXqsFQydsL2zNexCrbXAhdQg/o0qOlWnPaUd5ET8O8xXFq2qXizhjz9hm8lB/m380S
	 rSgJvIQe9mkSHyde2wHEwBXWQYEUPeH+ZLIz8k4c=
Received: by calimero.vinschen.de (Postfix, from userid 500)
	id 3803DA80C9A; Fri, 25 Aug 2023 14:23:16 +0200 (CEST)
Date: Fri, 25 Aug 2023 14:23:16 +0200
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: [EXTERNAL] Re: scp stalls on uploading in cygwin 3.5 current
 master.
Message-ID: <ZOidNPZSXvaecVJc@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>
 <ZOcb9SKtMPTQfj/m@calimero.vinschen.de>
 <20230825174832.9ebae8112667d5d5411cb8db@nifty.ne.jp>
 <ZOiHkCWY7PK3livD@calimero.vinschen.de>
 <DM8PR09MB70957918F669340C497F48D5A5E3A@DM8PR09MB7095.namprd09.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <DM8PR09MB70957918F669340C497F48D5A5E3A@DM8PR09MB7095.namprd09.prod.outlook.com>
List-Id: <cygwin.cygwin.com>

On Aug 25 12:08, Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin wrote:
> > I don't have an answer to this problem yet.
> > 
> > Can we use send(sock, "", 0) to reenable FD_WRITE, perhaps?
> 
> Can't it just be assumed that the socket is _always_ writeable _unless_ the last send() failed?
> In other words, try to always send() if it did not fail before.  If it did, only send() after
> FD_WRITE was returned in the event mask.

You're looking from the application perspective, but as the underlying
library we don't have the application under control.  The application
can rightfully expect POSIX-like behaviour from select(2), and *that*
means, it can expect select(2) to return a socket as non-writable if the
internal buffer is full, *before* it calls send:

  while (...)
    {
      /* send as long as we can, otherwise do another job in the meantime */
      while (select (..., <zero timeout>))
	send (<blocking>);
      <do something else>
    }


Corinna