Preemptive Threading

I recently wrote a blog post about threading: Improved threading for Xojo

And since a small part of Xojo can be used safely in a preemptive-thread, I went further and made a new function: CallDelegateOnPreemptiveThreadMBS

The way we handle it seems to be safe so far and we have no crashes. To show how this could be used, I made a little example, which does some math over memory blocks:

Please note that some rules apply so far:

Experimental function to play with preemptive-threads in Xojo apps.

Some rules:

  • No objects, no strings, no arrays
  • Use Ptr, not Memoryblocks
  • Crashes in debugger, so only use in built app
  • Use #Pragma BackgroundTasks False
  • Use #Pragma BreakOnExceptions False
  • Use #Pragma StackOverflowChecking False
  • Use #Pragma NilObjectChecking False
  • No exceptions
  • Delegate must be stored in global variable to avoid it getting freed early.
  • You can pass up to one ptr as data parameter.
  • Declares may work, but should be pre-used to make sure they don’t raise an exception and are loaded.

uses thread pool on iOS, macOS and Windows. Otherwise regular threads.

I tried it on macOS and Windows and it seems to work fine so far using 4 CPU cores.

If you like to try, please download 23.1pr5 plugins (or later). Links on the blog.


This has always been safe, just very limited use. (Due to the memory manager with that linked list that so badly needs mutexes to make it safe).

1 Like

I read the blog post. But I haven’t a clue what I can do with the callbacks or the new function. How does it help me?

1 Like

Well, Beatrix, with your Mail archiver app, it won’t help you at all.

But someone, who would do number crunching on a memoryblock, they could find a use for this.

Has 23.1pr5 been withdrawn, I can see it in your MBS Plugins forum post but not in the download links?

Sorry, I’m uploading it now.

Doing a release is a long list of steps and I forgot to move the files to the upload folder :frowning:

Will take something like 10 minutes.

1 Like

And uploaded. Sorry for the delay.

1 Like

I’ve demonstrated the same in pure Xojo code a while ago, too:

and even earlier:


I just read that whole thread from top to bottom and it looks to me that the same conclusion was reached then as now. The framework is not thread-safe enough for general use and the parts that are (pointers, structs, booleans and declares) are just too small coverage to make it practical.

In fact, your own description of what’s going on is:

a global variable is incremented by one and also adds the incremented value to an array (named queue here) as a CFNumber. The Pushbutton code then retrieves the 100 CFNumber values from the queue and shows the last one.

Even Norman posted in that thread (after a discussion with Joe Ranieri) that it would probably make more sense to write the code in C.

I know everyone wants this to “just work” but what you are describing is only good for the very few of us that do a lot of regular Objective-C and declare work because that’s all that’s not going to crash people’s apps.

1 Like

I think you are not understanding, some of us and more than one of us, that includes me and Christian and TT and others have spendt more than 24 years researching the Xojo framework.

Threads do work fine. Only thing that is needed to get it to work for everything (Except UI of course) is to fix the central memory reference manager (Which I have even provided the code for how to fix it).

Then pretty much everything works.

Q: Will everything be thread safe ?
A: Absolutely not, but it does not matter most objects you use in one thread not across threads. Same as in other programming languages where only very few classes are thread safe since usually very little uses same instance across mutiple threads.

Fixing the central memory unit would put threading capabilities on par with most other languages.

Why always try to sell Xojo short ? Its not rocket science and its silly to bash Xojo for years and years and say no this cannot be done in Xojo. Of course it can be done in Xojo like in all other programming languages.


Yes, from the outside. As someone who worked at Xojo for 11 years, I was fortunate enough to work on the frameworks with Joe Ranieri, Joe Strout, Norman Palardy and William Yu over those years. We discussed this topic several times during those years and we always came to the same conclusion… that it just wasn’t worth the time & effort.

Would preemptive threads be nice to have? maybe. Do I think they’re ever going to rise high enough on the priority list to actually get something done for the 20 or so users who want them but are not in their primary target market? No, I do not.

But I still think it’s incredibly misleading for Thomas to post a message like this:

I’ve demonstrated the same in pure Xojo code a while ago, too:

when in fact the user can hardly do anything in Xojo code using the example he gave. I don’t think it helps the community or the product because people tend not to read the whole thing when one links to a long thread like that. I would not have even commented had he said after that statement:

TL;DR - you can do all this as long as you only use Declares and assignments to Ptrs, Structs and Booleans and as long as you use a pragma to turn off StackOverflowChecking, BoundsChecking, and NilObjectChecking…

1 Like

They can hardly do anything because it stops on the Memory reference manager which is missing the few well placed mutexes to fix everything. That is the whole point of the matter.

Luckily those that worked on other languages and frameworks did not come to same conclusions. Since I am not sure where computing would be then.



I suspect that this will be the outcome.

Especially as preemptive threads are only one part of the missing concurrency capabilities that are available in other tools. Still needs the ability to synchronously run multiple microtasks soaking up every available CPU cycle to complete a task in 1 / ( coreCount-1) of the time, and no Helpers are not as efficient in terms of coding requirement or capability.

I’d like to be proved wrong.

I couldn’t agree more. Helpers are not as efficient, period, exclamation point!


Isn’t this sentence the opposite of what Geoff said in another thread?


Maybe you were over thinking the solution?

I imagine more than 20 users would benefit from this. It would potentially remove some nasty blocking from the UI, allow better concurrency in mobile apps and generally make Xojo a more useful tool.

I’ve followed the various discussions on this topic over the past 15 years and I get the impression there is a mismatch between what Xojo thinks we want and what we really want. Would it really have been that difficult to trial this by releasing a proof of concept with a basic implementation and asking the community to see how far they could push it?


If you’re going to pull a single sentence out of his answer, sure but his complete answer is:

What Greg is saying here is correct. There are a LOT of limitations to preemptive threads which is why applications tend to use processes these days instead which is exactly what you get when you use the Worker class. Large parts of macOS, Windows and Linux are not thread-safe. We could quite easily make preemptive threads available but then your apps would start crashing every time you accessed something that you didn’t realize was not thread-safe. If we spent the time to go through the framework to make sure you’d get an exception if you tried to use parts that were not thread-safe (a project that we believe would be measured in years not months), there wouldn’t be a lot left.

My question is whether that’s a good use of their time.

1 Like

Not even a whole sentence - a part of a sentence. That’s not a very honest debating tactic.

1 Like

We would not add something that could easily crash apps and then tell users to be careful. That’s not what we do. Our users expect us to guard against such things. At the very least we’d have to document what is and is not thread safe which would mean doing an extensive code audit.

The only way we would likely ever make this available would be by going through all the frameworks and making each and every method and property that is not thread safe raise an exception if accessed from a preemptive thread. That at least avoids crashing.

In nearly every case I can think of when a user’s app is crashing due to something in the Xojo language or framework, we consider that a very serious bug.