This is the mail archive of the
mailing list for the Cygwin project.
b20.1: fhandler_serial.cc: stuck error: fAbortOnError & ClearCommError is never called
- To: cygwin at sourceware dot cygnus dot com
- Subject: b20.1: fhandler_serial.cc: stuck error: fAbortOnError & ClearCommError is never called
- From: Stas Maximov <stmax at pigeonpoint dot com>
- Date: Fri, 24 Sep 1999 11:56:52 -0700
- Disposition-Notification-To: Stas Maximov <firstname.lastname@example.org>
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.
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.
1. Make fhandler_serial::open to be consistent with
fhandler_serial::tcsetattr, i.e. both of them will set
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!
I am willing to fix it. Do I have to subscribe to cygwin-developers
Want to unsubscribe from this list?
Send a message to email@example.com