This is a very exciting development and will open opportunities for a new “breed” of Xojo apps which natively support multi-core processors (basically all of them today, right??) with fewer compromises than workers.
Kudos to @Geoff_Perlman and the whole Xojo team for making this happen. I’m sure it was a huge amount of work behind the scenes to get Xojo ready for pre-emptive threading.
Can’t wait to hear more about it! 
This is a welcome announcement, but it is also a surprise, not having been listed on the roadmap.
Much of that “work behind the scenes”, I’m sure, is still ahead 
Hopefully, this will be more useful than the workers.
the evil is in the detail.
Like how they implement it.
Like we need a few mutex to control access to global things.
But if possible just do atomic operations without mutexes for better performance.
If they use too many mutexes, the benefit vanishes.
Also I may need to go through our plugin functions and see what you guys like to use and add a few mutexes and atomic increment/decrement myself.
Would it be possible to use AppleScript with a preemptive thread? I still get the beachball when an AppleScript takes too long.
If this documentation from Apple is up to date then the answer is no:
Have you tried using the osascript command running in an asynchronous shell?
Can confirm this will work.
Most of my scripts are executed multiple times with script properties.
However… if other heavy tasks can be passed off to preemptive threads, it leaves more “free time” for cooperative threads (the only kind we have today) to do more work.
Obviously, it depends on your app design, and as Christian said, “the evil is in the detail”, but… this feels like a step in the right direction to me.
I believe preemptive threads will be a real improvement over workers since the threads will be part of the “main application” and therefore should have much better access to all of the application’s resources (which is almost certainly where the critical sections and mutexes will come into play) vs. the “narrow tunnel” we get to pass data back and forth with Workers.
Processing of large data sets (without having to pass them back and forth through a "thin channel the way workers do) and filesystem operations seem like good candidates for preemptive threading for my personal use cases. I’m sure there are many more opportunities, especially for plug-in makers.
Overall, an exciting topic.
Yikes - that page is from 2014 and is in the Documentation Archiver. I definitely would not rely on it.
Don’t get me wrong: This is a fantastic move and we asked for this for 20+ years.
But expect a lot of crashes.
I will basically have to go through plugins and over time and additional checks to make functions thread safer.
It takes some work but can be done. I’ll see if I can post example code later.
@Christian_Schmitz: so you’re saying I’ll need to update my avatar to not just have goggles, but a crash helmet too? 
Its extremely old but there doesn’t seem to be any newer information available.
Can you explain further as I don’t think that would stop you.
I just hope that running things on legacy mode don’t get affected too by the changes or Xojo will get a layer of discredit breaking everything, old and new, instead of an upgrade on its image to the market.
Here you go:
If they document it correctly so the ins-and-outs are known and how to use it is known (including what can be done to get things wrong) then there will be not so much issues as if it’s just “dropped” into the framework.
Xojo can do such thing, but docs and use-cases etc would be helpful for these kind of threads.
We look forward to have this rock solid.
The web framework could benefit a lot from this. All the xojo code to parse requests and assemble the html & JavaScript could use this.
But you also have to learn how to use it.
Like you can’t use for each over a dictionary while another thread adds/removes a key.
Quite a few things that are fine today will need different coding to work preemptively.
There will need to be a low-overhead way of protecting a sequence of code from being interrupted. Back in the 1970s when I was doing this sort of stuff on bare metal (well, a PDP-11 actually), it sufficed to disable interrupts for a few instructions, then re-enable them. Cheap.