X-Recipient:	archive-cygwin AT delorie DOT com
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:subject:to:references:from:message-id:date
	:user-agent:mime-version:in-reply-to:content-transfer-encoding
	:content-language;
	bh=EtL7CcnXA/9HNoHmOLt6MK1XmSCq+1Pu+RTLMjr8fxA=;
	b=NyXcpn4z6vNtm9+firqDnS5xmdQbFuxRDIUlV5cG7yEAqYpodvoOIlVkr9yXhE9tJ5
	ri5y2K6jM4vzag1Y/pHT6ztnAT0S71nBCdj5UQAFduDdOsUU4FbQlZ1SEEK3CrJlI5nG
	fgAeor0Khxib0gAQOOBrcVrQU0nAE6KFbh8YchGWkIUNhK8FtLDN8zBksI9YfzJtSco9
	c3Y+Czjc2DFvrCun0539/pYU97aSZjM89pftNWOU89SMPw/IFzFyAtJQ0scgW+G8/XzR
	xAKxsNJ4b+ExcWdPqE/72NbP2a9aGN73JLME8dySWvzbHA3/fvmp6br/gdCW97GR7OOT
	tfWQ==
X-Gm-Message-State:	ANhLgQ2WKZZYkOc893jgHOq3cYLRrGlWS7ToXmTctIm0mjIR0P7WGB50
	8LjCdk3v+gko/9nvkPYrybKFNfMspkU=
X-Google-Smtp-Source:	ADFU+vspPfOiqaovp42Cj20CFsUhkzBJMp+KwSvU6VzHZsL74/oYp5+RgklktgWqwyGeDhVxrtzV7Q==
X-Received:	by 2002:a19:2247:: with SMTP id i68mr5371567lfi.168.1584022807358;
	Thu, 12 Mar 2020 07:20:07 -0700 (PDT)
Subject:	Re: Setting termios VMIN > 0 and VTIME > 0 on non blocking file
To:	cygwin AT cygwin DOT com
References:	<9e4c6428-59de-df07-9e33-44ba95d5497f AT gmail DOT com>
	<20200312114041 DOT GJ4042 AT calimero DOT vinschen DOT de>
Message-ID:	<365dd437-7553-eb4e-3253-aba3bab74895@gmail.com>
Date:	Thu, 12 Mar 2020 15:20:02 +0100
User-Agent:	Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101
	Thunderbird/68.5.0
MIME-Version:	1.0
In-Reply-To:	<20200312114041.GJ4042@calimero.vinschen.de>
X-Spam-Status:	No, score=-24.6 required=5.0 tests=BAYES_00, DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GARBLED_BODY,
	GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3, RCVD_IN_DNSWL_NONE,
	SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2
X-Spam-Checker-Version:	SpamAssassin 3.4.2 (2018-09-13) on
	server2.sourceware.org
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.29
List-Id:	Cygwin mailing list <cygwin.cygwin.com>
List-Unsubscribe:	<http://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<http://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<http://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	=?utf-8?q?=C3=85ke_Rehnman_via_Cygwin?= <cygwin AT cygwin DOT com>
Reply-To:	=?UTF-8?Q?=c3=85ke_Rehnman?= <ake DOT rehnman AT gmail DOT com>
Errors-To:	cygwin-bounces AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces AT cygwin DOT com>
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id 02CEkx3d025973

On 2020-03-12 12:40, Corinna Vinschen wrote:
>
> I inspected the serial I/O read function and I only see a subtil
> difference in terms of VMIN/VTIME which doesn't seem to be the culprit
> at first glance.  In O_NONBLOCK mode, the underlying Windows function
> ReadFile is called unconditionally.  My current hunch is this:
>
> - If VMIN>0 && VTIME>0, the Windows equivalent of tcsetattr is
>    told that VMIN>0.
>
> - So, assuming VMIN == 2 in Windows.  If VTIME > 0, the Cygwin read
>    function sets the number of bytes_to_read to 1 (this is old code,
>    don't ask why).
Do you have a pointer to this? I can not find it...
>
> - My assumption now is that the ReadFile function fails because it's
>    supposed to return only 1 char, but VMIN is > 1.
>
> There are two issues here.
>
> - If my assumption is correct, the tcsetattr function must not
>    set the Windows VMIN equivalent to != 0 in the O_NONBLOCK case.
>
> - Also, as mention above, if VTIME > 0, Cygwin's read sets the number of
>    bytes_to_read to 1.   Weirdly, it does so even if there are more than
>    1 byte in the inbound queue.  This sounds wrong to me.
>
I think the problem is if the number of bytes requested are more than 
what is in the buffer it is going to overlap the read function (because 
of VTIME) and immediately after that CancelIO is called. Contrary to 
what is mentioned in the source code I think CancelIO is actually 
discarding data...

   /* Use CancelIo rather than PurgeComm (PURGE_RXABORT) since
          PurgeComm apparently discards in-flight bytes while CancelIo
          only stops the overlapped IO routine. */


My suggestion is the following patch:

diff --git a/winsup/cygwin/fhandler_serial.cc 
b/winsup/cygwin/fhandler_serial.cc
index 69e5768f6..afa8871bf 100644
--- a/winsup/cygwin/fhandler_serial.cc
+++ b/winsup/cygwin/fhandler_serial.cc
@@ -898,7 +898,11 @@ fhandler_serial::tcsetattr (int action, const 
struct termios *t)
    {
      memset (&to, 0, sizeof (to));

-    if ((vmin_ > 0) && (vtime_ == 0))
+       if (is_nonblocking())
+       {
+               to.ReadIntervalTimeout = MAXDWORD;
+       }
+    else if ((vmin_ > 0) && (vtime_ == 0))
        {
         /* Returns immediately with whatever is in buffer on a ReadFile();
            or blocks if nothing found.  We will keep calling 
ReadFile(); until


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -