See https://stackoverflow.com/a/34945814/1655275
> pselect signals that file descriptor is ready and
> ioctl(fd, FIONREAD, &len) returns zero len.
Failure to detect this condition has been revealed by
the testsuite:
=== RUN TestDisconnectingPortDetection
2017/07/27 13:56:37 PR - Connecting to Probe
2017/07/27 13:56:37 > Searching for port 2341:8037
2017/07/27 13:56:37 Detected port '/dev/ttyACM0' 2341:8037
2017/07/27 13:56:37 Using '/dev/ttyACM0'
2017/07/27 13:56:37 Starting test (timeout 20s)
2017/07/27 13:56:37 PR - Turn ON target
2017/07/27 13:56:37 TR - Connecting to Target
2017/07/27 13:56:37 > Searching for port 2341:8036
2017/07/27 13:56:37 Detected port '/dev/ttyACM0' 2341:8037
[...cut...]
2017/07/27 13:56:46 > Searching for port 2341:8036
2017/07/27 13:56:46 Detected port '/dev/ttyACM0' 2341:8037
2017/07/27 13:56:46 Detected port '/dev/ttyACM1' 2341:8036
2017/07/27 13:56:46 Using '/dev/ttyACM1'
2017/07/27 13:56:46 T2 - Make a Read call
2017/07/27 13:56:46 T1 - Delay 200ms before disconnecting target
2017/07/27 13:56:46 T1 - Disconnect target
2017/07/27 13:56:46 PR - Turn OFF target
2017/07/27 13:56:46 T2 - Read returned: n=0 err=nil
--- FAIL: TestDisconnectingPortDetection (9.18s)
Error Trace: serial_test.go:100
Error: An error is expected but got nil. %s
Messages: Read returned no errors
this commit fix the problem above.
This commit fix regression test TestConcurrentReadAndWrite.
Even if the test checks purpose is another it has detected
anyway that the returned error is incorrect.
Another specific test for closing port detection will be added
in the future.
The -D option tells it to print something just before starting the
transfer phase, which should be enough to ensure that all the file
links are available without having to guess a suitable timeout.
The only way to interrupt running Read() method of io.Reader is to call
Close from another goroutine. What happens is that go runtime builtin
race detector complains about unsynchronised access to "opened" member,
which is set in Close and checked in Read.
It doesn't seem to be dangerous, but 1) you never know, and 2) it makes
your life more difficult when you need to debug some other data races in
a complex project that uses serial.
Proposed fix changes simple access to "opened" to atomic operations.
It's also supposed to fix#38
un-commented Product member of the struct PortDetails. This goes with the pull request "completed retrievePortDetailsFromDevInfo #40". Apologies for not submitting together...
in retrievePortDetailsFromDevInfo:
- updated call to setupDiGetDeviceRegistryProperty with the same style used elsewhere (first get the reqSize, then call)
- use of generic variable names, in case the function is extended to fetch other values than spdrpFriendlyName (or spdrpDeviceDesc)
- re-enabled the assignment of details.Product