Subject: Re: b20.1: fhandler_serial.cc: stuck error: fAbortOnError & ClearCommError is never called
From: Chris Faylor <[email-masked]>
To: Stas Maximov <[email-masked]>
Cc: [email-masked]
Date: Fri, 24 Sep 1999 17:50:49 -0400

On Fri, Sep 24, 1999 at 11:56:52AM -0700, Stas Maximov wrote:
>Description:
>
>If parity error INPCK & !IGNPAR and parity error happens on serial port
>(replugged cables on the fly, while app holds the port's descriptor),
>all further read/write calls fail with EACCES.
>
>Explanation:
>
>fhandler_serial::tcsetattr sets Win32 DCB::fAbortOnError that means that
>any error condition on the port (and parity is one of them) will abort
>IO operation ReadFile/WriteFile with ERROR_OPERATION_ABORTED(995) and
>all further IO operations will fail with the same error till
>ClearCommError is called.
>
>fhandler_serial::tcsetattr sets DCB::fAbortOnError, but never calls
>ClearCommError to clear the error condition.
>
>Another thing is that fhandler_serial::open does not set
>DCB::fAbortOnError, so the behavior is different when you use default
>settings and try to set the default settings using tcsetattr.
>
>Solution:
>
>1. Make fhandler_serial::open to be consistent with
>fhandler_serial::tcsetattr, i.e. both of them will set
>DCB::fAbortOnError.
>
>2. Modify fhandler_serial::raw_read/raw_write that will basically use
>fhandler_base::raw_read/raw_write, but in case ERROR_OPERATION_ABORTED
>happens, they will proceed according to termios settings on the device.
>
>3. Add termios as a member to fhandler_serial. Check if fhandle_union is
>still fhsndle_console after that!
>
>Question:
>
>I am willing to fix it. Do I have to subscribe to cygwin-developers
>list?

Take a look at some recent snapshots.  The serial code is different now.

cgf

--
Want to unsubscribe from this list?
Send a message to [email-masked]