You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a mix of async and synchronous code in the SensorVehicle-main application.
Async/await should be used "from bottom to top".
When the code is running on a PC (against the simulator), the implementation for IVehichleCommunication that is used is "SimulatedVehicleCommunication". This utilizes an AppService to communicate with the simulator, which only offers async methods.
When the code is running on the physical car, the implementation for IVehicleCommunication is "VehicleCommunication" which utilizes the UWP I2c library. This offers only synchronous methods. Async is not an option here.
For this reason, we have been forced to mix async and non-async code.
The way we have solved this:
Inside "SimulatedVehicleCommunication"-class:
When sending data to simulator (setting wheel speed) we send without awaiting the task.
Problem caused by this: any exceptions that occurs behind this method will be swallowed since we are not awaiting them.
When requesting data from simulator we force the method to run synchronously by adding ".GetAwaiter().GetResult();" to the async method.
Potential problem: may cause code to deadlock, however this has not occured while we have been testing the code.
Better way of fixing issue - if async I2C library can be found
If Microsoft releases an async version of the I2C library, then it would be better to rewrite all the code to async, since this would also ensure that the GUI remains responsive.
(If I2c communication fails there will be approximately a seconds delay before an exception is thrown. If the update was initiated from the GUI, this will cause a momentary UI freeze).
PS: This suggestion for fix is only relevant if an async I2c library can be found.
The text was updated successfully, but these errors were encountered:
There is a mix of async and synchronous code in the SensorVehicle-main application.
Async/await should be used "from bottom to top".
When the code is running on a PC (against the simulator), the implementation for IVehichleCommunication that is used is "SimulatedVehicleCommunication". This utilizes an AppService to communicate with the simulator, which only offers async methods.
When the code is running on the physical car, the implementation for IVehicleCommunication is "VehicleCommunication" which utilizes the UWP I2c library. This offers only synchronous methods. Async is not an option here.
For this reason, we have been forced to mix async and non-async code.
The way we have solved this:
Inside "SimulatedVehicleCommunication"-class:
When sending data to simulator (setting wheel speed) we send without awaiting the task.
Problem caused by this: any exceptions that occurs behind this method will be swallowed since we are not awaiting them.
When requesting data from simulator we force the method to run synchronously by adding ".GetAwaiter().GetResult();" to the async method.
Potential problem: may cause code to deadlock, however this has not occured while we have been testing the code.
Better way of fixing issue - if async I2C library can be found
If Microsoft releases an async version of the I2C library, then it would be better to rewrite all the code to async, since this would also ensure that the GUI remains responsive.
(If I2c communication fails there will be approximately a seconds delay before an exception is thrown. If the update was initiated from the GUI, this will cause a momentary UI freeze).
PS: This suggestion for fix is only relevant if an async I2c library can be found.
The text was updated successfully, but these errors were encountered: