summaryrefslogtreecommitdiffstats
path: root/core/planner.h
diff options
context:
space:
mode:
authorGravatar Linus Torvalds <torvalds@linux-foundation.org>2018-06-20 15:03:57 +0900
committerGravatar Dirk Hohndel <dirk@hohndel.org>2018-06-20 16:38:04 +0900
commit21d6531e457a3c405725a88c42f525425d0831bf (patch)
tree253ea388a759cf18529651bcdbf52ce890dd6583 /core/planner.h
parentb75eae95c194452499ba73e606c0bc0b41d3fb32 (diff)
downloadsubsurface-21d6531e457a3c405725a88c42f525425d0831bf.tar.gz
qt-ble: improve responsiveness of waiting for bluetooth data
Our model of waiting for 100ms before re-checking if we got a packet over BLE resulted in potentially horrendously bad latency for received packets. That isn't just a possible performance issue, it actually seems to cause IO errors with my Suunto EON Core. I'm not entirely sure why, but it might simply be some timing interaction, particularly since the IO errors seemed to primarily happen when the dive computer itself was also busy updating the screen (ie if you pressed buttons on the dive computer to switch to compass mode, for example). So replace the silly hardcoded 100ms "waitFor()" function with a WAITFOR() macro that checks the provided expression every time through the loop, which gets us a much lower latency (we basically check every ten milliseconds). The macro is not beautiful, but it WorksForMe(tm). This makes a huge difference to the reliability of the download for me, and might matter for some other dive computers too. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'core/planner.h')
0 files changed, 0 insertions, 0 deletions