Fix app freeze on engine stop when rig disconnected - #83
Merged
Conversation
…eleased PTT through a latch the main thread waited on with no timeout, and then closed the hamlib link, the serial bridges and the QMX and TruSDX sessions in line. With the radio gone those calls block: a wedged CAT command runs to hamlib's own timeout, and every HamlibRigControl method shares one monitor, so close() waits behind whatever is stuck. The USB bridge has the same shape, where close takes a write lock a stuck read still holds. Stopping now captures the rig references, hands them to the TX handler, which already owns rig I/O and queues them in order behind the wedged call, and returns. The transports are rebuilt in the same breath, so a restart never reaches a link that is still closing; that is why their construction moved out of onCreate and into createRigTransports. Unregistering the serial bridges stays on the main thread, because nativeUnregister clears one native global whichever instance calls it, and a deferred one could wipe the registration a restart had already made. The blocking release helper is gone, along with the ad-hoc thread that disconnected the network client. Verified on the emulator against a rigctld that accepts the connection and never answers. Before, the main thread sat in stopEngine for 5.06 seconds and the retry threw NetworkOnMainThreadException. Now stopping returns in 63 ms, the PTT release gives up on the TX handler five seconds later, and the next start reconnects.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
releaseRigPttForShutdownand the unboundedCountDownLatch.await()the main thread sat in, along with the ad-hocThread {}that disconnected the network client.onCreateintocreateRigTransports()Why
Stopping the engine with the rig gone froze the app. The release waited on a latch with no timeout, and
close()then ran in line behind it. EveryHamlibRigControlmethod shares one monitor, so a wedged CAT command held both for hamlib's own timeout, and the USB bridge has the same shape where close takes a write lock a stuck read still holds. On my tablet with the radio pulled mid-transmission that was nine seconds of dead main thread, which is long enough for Android to call the app unresponsive.Test
Need a rigctld to accepts the connection and never answer
For simulation without a real rig...
python3 -c "import socket;s=socket.socket();s.setsockopt(1,2,1);s.bind(('0.0.0.0',4532));s.listen(1);c,_=s.accept();input()"Connected to rigctldin logcat, then Stop.Rig control torn downshould turn up in logcat about five seconds later on the TX handler thread rather than the main one.On the emulator, before and after: