Closed hatfield-c closed 3 years ago
As a part of debugging this issue, I've begun analyzing the communication process that Python application uses to link together SUMO and Unity.
My hunch is that part of the cause of the bug described in this issue is the fact that multi-threading is used, both in Unity and in Python, and the application attempts to synchronize the threads in each of these languages. Furthermore, it would seem that the default behavior when an issue is encountered, is for the the Python and SUMO threads to try and to reconnect with each other, which I believe is what it causing them to hang in this way.
One of the first problems appears to come from the fact that the TCP server's socket is set in "blocking mode", which transfers control of script to another process, which in turn prevents the script from being ended in anaconda.
Overall, it looks like most if not all of the script by the original creators will need to be stripped out and replaced, as it is littered with numerous violations of best practices such as this.
Not only was blocking mode eliminated, but so was the multi-threading aspect of the Python scripts as well.
While it is reasonable that threading may be required again in the future, the implementation currently present was not well suited to the application's needs, and has thus been discarded.
This issue is now complete.
When the Unity application is ended, and then the SUMO application is exited, the anaconda CLI throws an exception, but does not return back to the normal CLI, and instead hangs, showing the exception until the Python task is manually ended using Windows Task Manager. There should be an intuitive way to end the Python task, without reverting to such obtuse measures.