Hang on sort button "double" (second) click

[rct]

On my Windows 10/Python 3.10 setup, rtl_watch will hang if sone of the sort buttons is clicked a second time.

There is a half second or so wait when the button is first clicked until the table repaints. It appears that if the button is clicked a second time, or a different button is clicked, while the button still appears to be depressed, the application will hang. The window is unresponsive and no more lines are output on STDOUT.

[hdtodd]

Thanks for this. I haven't seen that issue on Mac OSX or Raspbian yet (I tested for it during debugging), but I'll go back and try again. Disabling and re-enabling button press actions in those routines should fix that, so I'll try that out.

There are a number of situations in which the speed of the system will affect its reliability in response to various actions, and I'm sure I haven't anticipated all of those. I'll add it to my projects list and see if I can tighten the code up a bit to prevent them.

[rct]

There are a number of situations in which the speed of the system will affect its reliability in response to various actions, and I'm sure I haven't anticipated all of those.

Since I'm running on an x86_64 laptop with small amounts of data, I don't think it is speed of the system is a big factor. The 1/2 second or so lag I see when I click a button feels like it is probably related to having a TK event loop and an MQTT event loop.

[rct]

Took a very quick look, not long enough to really understand everything you're doing, but I saw you've bracketed the button callbacks with stopping and restarting the MQTT main loop.

Were you following an Tk/MQTT tutorial that said that would be a good idea? Or were you anticipating that you'd need to do that to make things thread safe?

Off the top of my head, I don't think those are necessary. It doesn't look like you are using threading (at least expliciItly). The good/bad news with Python is the global interpreter lock (GIL) so those functions are going to run to completion without getting preempted. I have to look a little deeper but while Paho's mqtt has launched a thread for managing the MQTT connection, the rest of the Python code is going to be run in essentially a single thread.

I've commented out the mqtt loop stop/start in the button callbacks. Now the response seems nearly instantaneous. I can't break the app by double/triple clicking.

[hdtodd]

Yes, it's still single-thread, since tkinter seems not to be thread-safe. I presumed that MQTT was doing something with threads internally and so wanted to avoid having my manipulation of the tables be trashed by something MQTT was doing in the background.

So I put the loop stop/start brackets on the chance that stopping MQTT before fiddling with the tables might let MQTT clear its incoming queue through on_message. In my testing, I always ran down the list of sorts, never clicked the same button twice in a row and so hadn't seen the problem until you pointed it out [ :-) ]. But yes, once I tried it I found it was repeatable. Once I added a 0.5sec delay after stop, that seems to be fixed.

However, there are still some funny interactions with GIL (at least on the Mac) that cause the program to hang occasionally when performing one of the button operations (including QUIT!).

I'll leave that on my list of things to explore further later, but for now I THINK I have the double-click issue solved.

Again, this is in the v2.0.0 branch (development): available for download. I hope to merge it into main shortly.