Thanks for the clarification. Timing-wise, however, it amounts to the same thing - the main loop is blocked and the UI is unresponsive until the thread has yielded. I’m really surprised no one ever noticed this before.
Well, I interpret it as doing what we say in the “Xojo ONE Thread cooperative model” needing time yielded to the internal time sharing system to distribute to those fibers. They “start”, just don’t “run” until having an enough slice of time yielded to them. But this topic may be a little advanced and even a bit hard to describe in few words in the superficial docs. Xojo could add an entire topic to this part.
Having a preemptive model instead of a cooperative one would help.
Having real threads instead of fibers would be great.
Having asynchronous functions and futures and explicit waiting instructions would add exact synchronization and fine control to fibers too.
As we don’t have it, we need to fine tune things yielding time in exact places as we desire.
1 Like
We notice, and we handle it using the current available options, when possible.
Show me the forum posts mentioning this issue 
Sure, I get it. It starts exactly at that point … but it doesn’t do anything until later. The same as when we write SerialPort.send or whatever it is, that’s when it sends … but, oh wait, it doesn’t actually send anything at that point. It waits until later.
That’s the way it is, and it’s absurd.
Since it’s been mentioned, I’ve said this before: “cooperative threading” isn’t a real thing. It’s a made-up term. All it means is, the threads are real threads like other languages offer. Real threads act like independent processes, and aren’t held up by some glorified traffic cop. These aren’t real threads.
I don’t write in the forum every piece of thing I find and “fix”. But I can guarantee I handled threads vs UI before.
2 Likes
Cooperative threading means the threads are not like real threads the other languages offer. Xojo threads are not real.
If you imagine your Xojo execution as a series of blocks, threads help break up and rearrange the blocks to provide the illusion of multiple processes happening at once.
It’s this illusion that has tricked the folks in this discussion that don’t seem to understand that’s how it works. The CallLater trick is just that, a trick that re-arranges the blocks slightly differently. Everything still takes the exact same amount of time.
1 Like
Neither do I, but wow, this is kind of a big and fiendishly subtle potential issue for a lot of people, I’d have thought it worth sharing.
1 Like
That’s understood by most. The main point of Xojo threading, however, is to be able to maintain a responsive UI while iterative or otherwise blocking process are run. So if some aspect of thread usage actually blocks the UI, it’d be best if that were documented imo.
The only thing I’m trying to get at is that I don’t want the framework to rearrange the blocks when I haven’t asked it to. If I call Thread.Start, I want the very next command to be the first one in my thread.
If you don’t want that to be the case for your program, you may use the CallLater trick.
I already agreed with that twice in this thread, once to you and once to Rick
Of course, but this would likely break a lot of code.
Since xojo currently DOES NOT support preemptive threads, there are zero lines of code using it. How exactly introducing something new is going to break code? 
How about adding a sentence plus sample code to the documentation in xojo for the thread.start method to show this callLater trick do new developers?
10 Likes
Great suggestion
Has anyone submitted a request?
If preemptive threads were added as a new construct, that would be one thing. But the tone of the discussion here seems at times to be that we don’t like the existing cooperative threads, throw them out and replace with preemptive threads.
I do not believe that is the tone of this thread, maybe a few discussed it but the main point i got from this discussion was how we can deal with cooperative threads now in Xojo
Well, this is weird, I was well aware that xojo threads are not real threads, and that the total time to complete all the “code blocks” is actually a little more because the time used by the Scheduler.
However, since the main reason for xojo threads to exists is to provide a better user experience, I was under the mindset where expected the same result as Julia (All the Starst called before the threads actually started).
I always believe that Threads started AFTER the calling method ended, to allow the main thread finished the UI part to provide the better user experience 
I just put the Me.Sleep(1) on a couple Run Events and my app feels snappier and responsive 
Xojo really needs to step up on this:
Documenting to make it clear that the Start will make a context switch making the UI unresponsive until the first yield of the thread.
And implement something like a StartLater to fulfill the suposed goal of Threads, “to provide a better user experience”
Who wants to make the Issues?
1 Like
I’ll even write it for them:
"Note that the Start method does not return until the code in the thread’s Run event has yielded. Depending on the nature of the code in the Run event, this can result in a delay of 100ms or more, during which time the main thread (if Start was called from the main thread) will be blocked, causing the UI to be unresponsive until Start returns.
This can be avoided by calling Start from a timer as shown in the following example…"
1 Like
Anybody wanting this functionality today can simply make an extension to the Thread class:
Public Sub StartWithYield(extends t as thread)
Timer.CallLater 1, AddressOf t.start
End Sub
2 Likes