Run code for different hardware on different threads

[alexdewar]

Currently the program is largely single-threaded and it presents the risk that one faulty sensor could bring down the entire system. One option would to use separate threads for each hardware module, but it may also be possible to write it using async/await instead.

[alexdewar]

While this task is v doable, it will introduce possible race conditions all over the place.

It's probably best if it waits until I get back.

[cc-a]

I had a look at this under sprint 18. From the issues as is, I don't sufficiently understand the rationale for introducing threads in order to proceed.

The need to have better fault tolerance could be readily solved by reviewing and introducing appropriate error handling for the current device interaction code. Adding threads into the mix doesn't seem to provide this in and of itself but just introduces a similar problem of gracefully handling crashed/hanging threads. Given the technical complexity of introducing threads and the noted potential issues with race conditions we'd need a strong reason as to why its the best way forward.

[alexdewar]

Given that we have run out of time on the project, I don't think this should be a priority.

For context though, the rationale was to prevent a single failing device from hanging the rest of the program. For example, if a USB cable comes loose and a device disappears suddenly, then currently the code might hang waiting for a response until it times out, during which time the GUI, data recording and interaction with other devices will also hang. We're particularly concerned about robustness on this project because if FINESSE crashes at 30,000 feet and data recording stops it could mean a wasted flight and wasted money.

That said, as you point out, adding more threads can create its own problems, so maybe let's just prioritise ironing out problems with the error handling paths in the existing synchronous code.

[alexdewar]

Superseded by #638