My program relies on a background thread to perform certain tasks.
I have it set up such that I can turn the background thread off. But then the program is not fully functional.
The only time I want to turn off the BG thread is when debugging. Because it only takes a half dozen steps in the debugger and its stepping into the BG process. Then the only way to get out is to put a breakpoint in the foreground thread and run to that.
To work around, I often just put a breakpoint on every line in the foreground, then run, run, run. Its ridiculous I know but I haven’t got a better solution yet.
I was just looking at #pragma debug false. Put that in the BG service routine, and it doesn’t break there. But it breaks in the methods the service routine calls. So put #pragma into those. So it doesn’t break in those. But it breaks in the methods they call. You see, it fans out. I can see how this behaviour has some application, but it isn’t this one.
Any thoughts on this matter? How to keep the BG thread running without having the debugger step into it.
I’ve never attempted to solve this, I’ve just suffered through it with a bunch of breakpoints as you’re doing. Some thoughts:
To expand on what @MarkusR said about conditionally breaking, I wonder if you could just do something like this:
#Pragma BackgroundTasks False // don't yield to background thread
If Thread.Current = Nil Then Break // break if in main thread
Depending on what you’re debugging, you might try using System.DebugLog to dump the relevant debugging data instead of stepping through the debugger.
Turning off background tasks interrupting within a method is good, though I wonder if that is the same basic problem as #pragma Debug False. Obviously I haven’t tried it yet. It would be great if one could turn the BG thread task switch off for an entire class or module.
I don’t totally understand Thread.Current = Nil, I’ll look that up.
Yes I use System.DebugLog a lot, though never thought of it as a workaround for this issue.
Thread.Current is a reference to the currently running thread. If you’re in your background thread then it would be a reference to that. If you’re in the main thread, Thread.Current is nil. So for methods that can be called by the main thread or background thread, doing If Thread.Current = Nil Then Break would only break when you’re in that code from the main thread. And then the pragma would presumably ensure you’re not switching contexts within that method. Seems like that might work.
When you debug non-stoppable asynchronous things, the only way to go is logging and observing logs. Stopping ONE THREAD to observe it will break the real behavior and even can create hard crash situations, other threads should be going on while you paused one, unless in cooperative mode, where the entire system will stop.
Cool. I didn’t know they added preemptive mode. My code has been around longer than since that was released. I will look into that.
Given that I work with microcontrollers, and thus with interrupts, I get what you mean, how some things you cannot use a debugger for. Debugging communications on a microcontroller is about impossible using a debugger. I typically flip bits and get out the logic analyser. But that is another story.
The background thread seems to work fine. Its running a service at such a high rate that it only takes a handful of lines of Xojo code until the debugger is into the background thread. In some microcontroller debuggers, you can specify not to step into the interrupt code. That is what I would like Xojo to do, ideally. But it doesn’t seem to do that yet.
There are a bunch of ideas to experiment with here. I haven’t tried any of them yet.