On 13 September 2018 at 21:44, Bill Perry <[email protected]> wrote: > Just a reminder that last summer I saw that the code in serial_ftdi_read() > doesn't guarantee that a timeout occurs > in the desired timeout period. > Due to the way it is written, you can get MUCH longer delays when the bytes > don't stream in right away or > This was an issue I was fighting last year when I was trying to get retries > to work on the Pelagic data cable with Android. > It actually affects any ftdi device. > This is likely an issue on Windows as well. > > ftdi_read_data() took a few milliseconds of time before returning and that > time is not accounted for. > And on android the the LIBUSB_ERROR_INTERRUPTED was also happening. > This caused the while loop to loop for several minutes before timing out. > My solution (which I posted a patch for to the list back in Nov 2017) was to > get rid of slept and to always sleep for 1ms. > Then rather than comparing slept >= timeout - which doesn't work, was to use > gettimofday() > to check for the elapsed time to check for the desired timeout period. >
sleeping for small chunks of time can end up being better. would you like to submit a github PR to address this improvement as per your experiments? lubomir -- _______________________________________________ subsurface mailing list [email protected] http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
