From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x243.google.com (mail-lj1-x243.google.com [IPv6:2a00:1450:4864:20::243]) by sourceware.org (Postfix) with ESMTPS id 3BC223942014 for ; Thu, 12 Mar 2020 17:04:12 +0000 (GMT) Received: by mail-lj1-x243.google.com with SMTP id f13so7309626ljp.0 for ; Thu, 12 Mar 2020 10:04:12 -0700 (PDT) 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=CfTnOrbfuSQpNDO5FCcT+IH0ZdjX9bFsfdsNEwQ/Vkg=; b=frZjh6WIvXZwtnLykVO5P5mCrAkX3ICosveS+5MS1C2k0qbFwvroioUibpiG3VosRc 9sudhHipSnKF4BPekzhVJlH90HInXvq6OOG9hNYhUB0rzyEsxXfAXMFCDsZCNPK+BSXG 8br/qcRxmh5u8BZuZPe0u3NSwxcEggFHjW8AOYphta3W5HQIucNFyUuk4RdlitKxIB6Y 9+RykfGZsY9qehvkWFmyAbjPoIDZ8LvZYCSyEy5zDVlmzXV6WCO+TqX4o6Weo2qfBuYs 58+TABE8Uo4XhMEGTkP42HpXtFJ6s5cWrjMp1ILHoJy0/EnVMMG4XMEsbS1YCQSdJPv0 aocA== X-Gm-Message-State: ANhLgQ2jotJ7UHQZ1C0ZJzL1xP1/TgUzGxHlz6F9ogXAQimVm0/+Nr2V ajHKueD5I5N4jWOfkTbHfIGWhvavAog= X-Google-Smtp-Source: ADFU+vufw1kD5pu1lWs4OnOtgFugs0hjX8VF1I8L7VMoVJL02GWhGxuL8lYCelxeqXcZLbhktMmHiQ== X-Received: by 2002:a2e:854e:: with SMTP id u14mr5722747ljj.27.1584032650585; Thu, 12 Mar 2020 10:04:10 -0700 (PDT) Received: from [192.168.1.117] (tb213-185-244-58.cust.teknikbyran.com. [213.185.244.58]) by smtp.googlemail.com with ESMTPSA id d8sm2135719lfm.1.2020.03.12.10.04.09 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 12 Mar 2020 10:04:09 -0700 (PDT) Subject: Re: Setting termios VMIN > 0 and VTIME > 0 on non blocking file To: cygwin@cygwin.com References: <9e4c6428-59de-df07-9e33-44ba95d5497f@gmail.com> <20200312114041.GJ4042@calimero.vinschen.de> <365dd437-7553-eb4e-3253-aba3bab74895@gmail.com> <20200312144445.GP4042@calimero.vinschen.de> <20200312150833.GQ4042@calimero.vinschen.de> From: =?UTF-8?Q?=c3=85ke_Rehnman?= Message-ID: <9e56e005-660b-373e-d557-9c8bc97c45ba@gmail.com> Date: Thu, 12 Mar 2020 18:04:05 +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: <20200312150833.GQ4042@calimero.vinschen.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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@cygwin.com X-Mailman-Version: 2.1.29 Precedence: list List-Id: Cygwin mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Mar 2020 17:04:13 -0000 On 2020-03-12 16:08, Corinna Vinschen wrote: > On Mar 12 15:44, Corinna Vinschen wrote: >> On Mar 12 15:20, Åke Rehnman via Cygwin wrote: >>> I think the problem is if the number of bytes requested are more than what >> To clarify: number of bytes == VMIN? no number of bytes requested from ReadFile(). As far as I know Win32 has no concept of VMIN. >> >>> 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... >> So far we didn't have that experience. CancelIO is usually safe >> in this regard. The data is MIA somehow... >> >>>   /* 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)) >> What if you switch to !O_NONBLOCK after calling tcsetattr? The >> setting of ReadIntervalTimeout would be lost then. >> >> Either we have to repeat calling SetCommTimeouts every time >> we switch mode, or we have to do the above setting temporary >> every time we call ReadFile in non blocking mode. True. > What about this: > > diff --git a/winsup/cygwin/fhandler_serial.cc b/winsup/cygwin/fhandler_serial.cc > --- a/winsup/cygwin/fhandler_serial.cc > +++ b/winsup/cygwin/fhandler_serial.cc > @@ -68,6 +68,16 @@ fhandler_serial::raw_read (void *ptr, size_t& ulen) > goto err; > else if (ev) > termios_printf ("error detected %x", ev); > + else if (is_nonblocking ()) > + { > + if (!st.cbInQue) > + { > + tot = -1; > + set_errno (EAGAIN); > + goto out; > + } > + inq = st.cbInQue; > + } > else if (st.cbInQue && !vtime_) > inq = st.cbInQue; > else if (!is_nonblocking () && !overlapped_armed) Looks promising. I will try it. BTW there is a gremlin in the "else if (ev)" line.... /Ake