I thought all this was common knowledge. It is up to the developer to tune thread yielding to balance throughput and UI responsiveness. It is very easy to write a thread that blocks the UI. Threads may yield on loop boundaries, but it’s not guaranteed. A judicious sprinkling of yields within the thread code is generally a good idea.
1 Like
We noticed it a long time ago. By chance some of our threads also need to run after opening a modal dialog window so we use the timer call later approach.
I think the only way this can be solved 100% is if the main thread was never blocked by other threads (ie: preemptive threading) but Xojo don’t want to give us what we want.
You can also change the thread priority on the fly. So depending on the stress there may be from other threads one can slow down some threads by giving less priority (time slice) and xojo will do the rest. You can also do vice-versa.
I’d call it StartLater, but otherwise, yeah. 
Renaming the method is left as an exercise for the peanut gallery. 
Ecept that most of the time, it doesn’t work. You should tune it yourself.
This is a preemptive model concept, a thread gets suspended at any point when its time slice ends and another thread resumes. In cooperative mode, if a “cooperative yielding point” is not reached, the thread keep going beyond the proposed time.
This is something else that keeps coming up, even though we have already been told that a lot of the Xojo framework is not preemptive-thread-safe, at least in part because the underlying OS libraries aren’t either.
My suspicion is that if we had actual preemptive threads, a lot of people would find that their apps failing in odd ways, because they’d not appreciate that their threads could be interrupted at any time by another thread.
I (and several others) have heard the same reasons (excuses) over the past 15+ years (GUI not thread safe / OS APIs not thread safe etc…). At the same time, it hasn’t stopped the majority of other programming languages from having a much better threading implementation than Xojo.
Xojo threads can interrupt each other today but only at specific boundaries.
Some of the issues are related to multiple threads accessing the same data so if the threads don’t share data or they use some kind of mutex / critical section / semaphore when modifying shared data there is less chance of something going wrong.
The topic has been done to death recently so there is (unfortunately) no point in rehashing it.
1 Like
In retrospect it all makes sense, but it was suprising to me, in my naiveté, that Start did not return immediately, that’s all. Once everything’s running, my threads don’t impinge much on the UI, but when their launching is initiated by a user action the lag is very noticeable, e.g. a pushbutton remaining highlighted for a second after clicking.
That’s no longer true. Once Xojo started being written in Xojo, framework calls that were once atomic can now yield on their own. You have to code accordingly.
Yes. I should have said known boundaries within the language as they are the same for all Xojo code.
lol, that is NOT how preemptive, actually it is the other way around, xojo “threads” interrupt themselves because are NOT real threads. Most tools do have preemptive threads and apps are NOT magically stop working just because.
His point is that Xojo programmers, accustomed to Xojo’s thread model, would find it a difficult transition - truly preemptive or symmetric multitasking opens up entire classes of bugs that are notoriously difficult to troubleshoot.