TwinFan
commented
5 years ago There are 2 places to work on:
- [ ] Waiting for an incoming TCP connection in
RealTrafficConnection::tcpConnection: The call totcpPosSender.listenAcceptwould need to be broken up as we should callacceptonly when there is a connection waiting, as that's the blocking call. - [x] Reading from the UDP sockets in
RealTrafficConnection::udpListen. There is alreadyselectcall which can be easily changed to either include a timeout or a self-pipe.
There are still two solutions: select with timeout, or the self-pipe trick, which doesn't look that complex at all once seeing example code.
However, needs a bit of testing to ensure it works well, especially on the TCP side. So not a fix for a rush.
Describe the bug See this forum post for details Basically: With RealTRraffic channel enabled the user experiences freezes on any inactivation activity (stop displaying aircrafts, deactivating the plugin, exiting XP).
To Reproduce User can reproduce by enabling RealTraffic channel (not actually serving data, ie. RealTraffic app did not run), starting to show aircrafts and then inactivity display of aircrafts.
I could not yet reproduce on Mac.
Expected behavior No freeze, at maximum a slightly delay.
Pre-Analysis Apparently linked to shut down of RealTraffic channel, which in turn has to stop 2 threads. This stopping of threads is a bit crude anyway: I‘m killing the network channels the threads listen to and hope for the threads to stop then. Maybe there are situations in which this way doesn‘t work.
A workaround would be to go back to a previous design to have the
selectwait for max. 1s and then start over. That would at least allow to safely catch a shutdown message. (There are more complex design in whichselectalso listens to an internal pipe...but I think that‘s over the top.)Technical Info:
Log.txt A common last log message is: