I have a desktop app currently running on macOS and Windows. It is built around an interactive thread class that contains and services a serial where a customer device is detected. This thread used to be preemptive but was changed to cooperative as I experienced data loss in a cooperative thread which does not appear when it runs cooperatively.
Interactive in this sense meaning the thread waits for user commands until being quit, so it runs in a loop, sleeping it for a short time periodically (as otherwise on macOS CPU consumption would be enormous).
Making this app run on Linux too seems impossible and I have no clue why, except for a suspected framework bug. (Tried Ubuntu and Fedora)
When run cooperatively, the GUI will stall completely without the main window being shown. It is registered in system view but shown as an empty frame in its preview. It is fully set up and visible in debugger but will not be drawn just for a brief moment before the app quits.
When the thread is run preemptively, things look a bit better as the app does everything it is supposed to do: Find and connect the device, check the server for updates … just that there is no GUI update until user clicks on a custom menu that is drawn on a Canvas. This also includes window resizes. The OS will show the resizing mouse arrow but the window will only be resized when I invoke that custom menu. Even the menu bar isn’t accessible, so it looks like the main event loop would only run if the UI update is triggered via this menu. I tried yielding and changing sleep periods, but all in vain, and I see no really chance to strip down this app to a simple sample.
And btw: Wasn’t it possible to profile a remote app? It is not for me, neither on Windows nor Linux, both running on a LAN connected Intel iMac with Parallels.
I’m sorry to hear of your troubles. I don’t have any advice, but I can answer this though:
When you turn on profiling for an app that’s being remote debugged the profile ends up in a text file in the remote downloads location. It doesn’t make its way back to the IDE.
I haven’t actually checked on this in a while, so I referenced this thread:
I have the same thing when updating on Ubuntu and raspberry pi OS. I am trying to communicate with another device through Bluetooth, and using a thread locks up the GUI.
I don’t have a working example program, because I thought it was just me.
I have programs that work in both c++ and in Python, so it’s not the operating system or those two languages.
Uh. Thank you, Eugene. Think we should file a ticket, even if no demo app exists.
And thanks a lot, @Tim_Parnell! Good to know. Do I suffer from Mandela effect thinking this once worked inside the IDE?
Sure, feel free to start a ticket. I’m busy on another project and won’t be able to look at this for another week. I’ve been trying to use declares to find out where the problem exists in xojo, and no success yet
This may have been the way that Xojo has always interacted with a GUI and Linux. Examples from my opengl programming book work just fine on Ubuntu and windows. These example programs have not used a thread before.
I just found that the Threaded Imgur Generator example project will at least show a bit of this behaviour: When set to cooperative, window cannot be resized and the OS will show an unresponsive app alert every few seconds.
Just creating a ticket …
Norman mentioned to me that he has seen this kind of issue as well. His solution was to use a Worker to separate the process. Perhaps that’s worth a try?
Project runs on macOS and Windows flawlessly, so I would like to avoid rebuilding it in a more complex and slower way for an OS that’s only been run by a handful of users so far. At least as long as I hope this can be fixed in the framework. It should be possible, as Eugene wrote.
Profiling while remote debugging has never returned the data to the IDE. if you need to review that data, there was an error external profile reader available at some point that would show the data and communicate double-clicks back to the IDE.
So I could finally fix it. I still don’t understand the reason UI was stalled, but it turned out it wasn’t the thread that was faulty but an asynchronous shell I kept running executing usbmon to be notified of when a device is (un)plugged. That shell works, but when I fire an event from this class to notify the serial thread to try a connection, it is as if this event never finishes and blocks everything. I found out rather accidentally by shooting the usbmon task while the app was running, when immediately all of the pending UI updates were performed. The stall also happened when I isolated the event with a timer, but anyway: I am now killing the shell once a connection has been made and go with a timer that checks for serialDevice availability regularly.
2nd weird fact is all will run on Linux only if the thread is set to preemptive mode. On Windows and Mac cooperative is the way to go as otherwise I sometimes lose serial data. But it works – sigh!
I worked on threads by using declares and have attached a simple program. There must be something that I am missing, as I am not able to update the Xojo UI by implementing a Raspberry Pi Operating System thread.
Edit: I can print text with System.DebugLog, but not update GUI controls.
Many things have been tried, such as App.DoEvents, trying to have other threads initiated (YieldToNext), added a separate timer, and so-far no success.
Glad you were able to get it working for your program.
Not fully working. I am using a HTMLViewer custom control (using WKWebView on macOS, WebView2 on Windows), and I verified HTMLViewer displays the site without issues on Linux too. But not so inside the app where the url will be loaded, but animations show extremely slowly and the viewer itself gets completely unresponsive to user input. Additionally every 5 seconds or so the system asks if I want to kill the app. As if there was a limit to parallel processes, or something floods the app internally with notifications so there is no more room for UI updates. According to system monitor there is plenty of it.
Anyway, I could replicate at least the usbmon part of my issues and attached it to the ticket. Will inform William about your project too. Thanks a lot!
Exactly so for me. And for the mitigation attempts with DoEvents, Yields, …
I even have a AtomicIntegerMBS (thanks, @Christian_Schmitz !) that keeps track of how many updates are pending, and it will always be reduced to 0 after a very short time.
To further add to thread-blocking, I have attempted work-arounds with bluetooth communication, and I am running into the same UI blocking issues. I am sure that Xojo will get threads working on the Raspberry Pi.
