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:
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.
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…
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.
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 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.
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.
