X-Recipient: archive-cygwin AT delorie DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 943AA3858C2D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com; s=default; t=1692969562; bh=mTRcqyku0FAlDlTq5KOMD0ZMABuV+2kFt0qj7rA1Tdw=; 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=o97YnmqOO9IU2VQeIc8wjZVu1ppgZqy/kEbdJ/3UaWdIkJiP4TwSpmplz/wFxl9zX CF4z1Euq8zP3YdYas56oo9gaiwU60IH9tBj2tKAeZdKzTDko1oDaAYvIGgx1j2UVrh WsrjK+gpcw+XreQowm2HmdxhOW6CFblzQHD/CMWU= X-Original-To: cygwin AT cygwin DOT com Delivered-To: cygwin AT cygwin DOT com DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E7A133858C53 Date: Fri, 25 Aug 2023 15:19:03 +0200 To: cygwin AT cygwin DOT com Subject: Re: [EXTERNAL] Re: scp stalls on uploading in cygwin 3.5 current master. Message-ID: 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> <20230825174832 DOT 9ebae8112667d5d5411cb8db AT nifty DOT ne DOT jp> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-BeenThere: cygwin AT cygwin DOT com X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Cygwin discussions and problem reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Corinna Vinschen via Cygwin Reply-To: cygwin AT cygwin DOT com Cc: Corinna Vinschen 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" On Aug 25 14:23, Corinna Vinschen via Cygwin wrote: > 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 (..., )) > send (); > > } No, wait. I just realized that this isn't correct. While select indicates that data can be written, it doesn't indicate how much data can be written. I. e., if select returns, and there's only buffer space for 10 bytes, and the send call tries to send 100 bytes, it *will* block, unless the socket is non-blocking and returns EAGAIN. The testcase my patch was based on called a poll/write loop on a socketpair without changing the socket to non-blocking before. At the time I didn't even realize that it's actually not a good test, d'oh. 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