Closed MajorMajor0 closed 3 years ago
You can have a look a the README.md
file. There I list some known issues. The README.linux
contains a concrete use case:
Flow Control
If you close the serial port while blocked (e.g. due to flow control), calling the serial_close() method may take an excessive amount of time. Times measured have been from 5 seconds to more than 21 seconds. It appears to be an issue in the Linux kernel when calling the close() system call.
Also, there are some test cases in this library, that when you have two serial ports and a NUL-Modem cable, you can observe some blocking issues. It appears related to USB and not the internal 16550A chipset found in most PCs (but usually no longer accessible).
However, I only notice the problems on Close()
, not on Open()
. Some people have observed mostly issues here when opening a RFCOMM BlueTooth port.
This is a question, not an issue--couldn't see where to mark it as a question.
In one application I have that use System.Io.Ports users have seen an issue where, when a serial port is in a bad state, SerialPort.Open() hangs for 30 seconds without throwing an exception. I am told this is somewhat common, though I can't find a any documentation for it and don't know how to recreate it. Using that API, I am stuck wrapping SerialPort.Open() in a Task that I can timeout and kill.
With apologies,