Workers are fine in some circumstances but not an adequate solution. I’ve added a request for true multi-core threads and laid out the case. If you agree, please sign onto the issue.
11 Likes
This has been talked about for years. If memory serves, the framework is fundamentally incompatible with true multithreading and would need a complete overhaul.
Totally agree that it would be nice. You mention a specific use case in your issue report. What kind of resources would need to be shared amongst your threads?
While true, this issue becomes more of a problem with each passing year. Single core performance is only going in one direction, and it’s not up. It can’t be ignored forever.
14 Likes
When Workers were introduced, multicore was marked as “delivered”.
https://documentation.xojo.com/resources/roadmap.html#delivered
1 Like
Technically, yes that’s correct. Practically… workers are impractical in a large number of scenarios. In my head, it’s easier to think of ways I can’t use them than it is to find ways to use them.
5 Likes
Workers are a nice idea, but if you needed this, you may have had already a similar solution with a helper console project run from your GUI project using shell class.
On the workers, I would love to see the Xojo IDE use workers for something.
Because by using it themselves day to day, the Xojo engineers would work on the limitations and improve it.
14 Likes
As it has been obvious for a good number of years that multi-core performance was the key to the future. If they had decided to bite the bullet and start on it years ago, instead of some the other things of questionable value they decided to do, it could have been here today.
I wonder which would have sold more licenses…
-Karen
4 Likes
To make workers more practical for more situations they need to create a good X-Platform API to use shared memory for information transfer.
-Karen
True use of all cores woud empower Xojo so much more, Xojo to the moon 
2 Likes
I’m sure that a lot of licenses were sold because prospective customers really wanted to have to prefix their controls with “Desktop” and write the modern CellValueAt() and RowTagAt() instead of the old-fashioned Cell() and Rowtag().
12 Likes
I actually gave Xojo source code for Sandbox safe shared memory, to help them implement this feature quicker… Years ago.
I’ve tried very hard to lobby for Xojo to work on better concurrency (and many other things), I’ve just concluded that they’re not interested.
In the end moving the most critical code to a “Modern” language like Objective-C (Sorry Kem), gave me what I wanted. The process was much easier than I anticipated, and didn’t even require Shared Memory as it could operate in the same memory space as the Xojo application.
6 Likes
I wonder what proportion of Xojo users would benefit from true multithreading, who don’t get what they need from Workers or console apps. I’m guessing it’s not a lot - I’m assuming that people who need that level of performance are already using other languages.
That’s kind of the conundrum. Pro apps / developers aren’t Xojo’s target. So there’s little desire to solve this. At best, we’ll get whatever they need to keep the IDE going. So if the IDE needs better workers, that’s when we’ll get better workers.
3 Likes
One use case is when calling a DLL/Dylib/Solib function that blocks execution of the main app because it assumes you are running on a preemptive background thread.
Maybe not the most common use case, but there is at least one commercial Xojo-made app on the market right now that had to be split into a desktop app for the GUI and a custom console helper app for the core business logic because of this exact problem. Doable, but shouldn’t have been necessary.
Though I do understand Xojo’s reluctance to arm newbie users with true multithreading (TMT). Maybe if they hid it behind a high knowledge barrier?
Like, maybe in order to make a TMT function call you’d have to create a new delegate type in your project and add a TMT=True attribute, then create an instance of the delegate from the function you want to call, and then call Invoke() which runs specified function on a TMT thread.
2 Likes
The IDE could definitely benefit from better multi-core support: seeing only 1 of many cores being used when running a debug build is painful (and repeated many times a day); loading plugins when launching Xojo; compiling plugins when building for the first time with a new version of Xojo or updated plugins.
7 Likes
I would like this for one of my app (an app to search for files/folders, given many properties you can choose, like the Mac OS 9 Sherlock app).
Currently, I’m using two apps: the UI app and an helper. At least, several concurrent searches take one core each, better than sharing the same one.
A worker couldn’t help, because I need to be able to cancel the search/skip a given folder, and an helper won’t accept inputs while it runs.
I also wouldn’t want to learn yet another language.
Xojo told us moving to multi-core threads would be not so simple than we think (I don’t recall the specifics; something like issues with the main event loop, or code re-entrance; things we would have really troubles with), so I agree to stay in a safe environment.
There are endless reasons why nothing else than real threads make sense.
Xojo apps are not power efficient, launching workers is not power efficient. World now is about efficiency. And CPU’s come with small cores and big cores and what not, where you need proper threading to make use of any of it.
World now is about microthreads…you could launch micro thread while waiting for answer from webservice for example. Your not going to launch worker, while you wait for response from one web service call. That is just not how things work.
Operating systems have both threads and workers for good reasons.
I have personally had to move apps largely away from Xojo like many others because of the threading issue, it is sad but true.
But I still keep hoping that one day this gets done right, as there is no future in programming if you plan to just live back in 1990 forever.
I even submitted C++ code to them in issue long while ago on how to make the Xojo memory management threadsafe which would be huge starter. As far as I know it got ignored. (It was this issue here: https://tracker.xojo.com/xojoinc/xojo/-/issues/68072)
With that said then I think its unrealistic to expect to wake up one day and whole Xojo is thread safe, such would have to happen in steps like fixing memory management first, then doing small basic core elements, making string thread safe, date, etc. But…with those small baby steps your pretty fast at a spot where you can do a lot. Just memory, string and date is already plenty for many things, which then can by built on to increase thread safety more over time.
19 Likes
This alone would be reason enough to invest time into it. Because there will (soon) be a time when “experts” will tell “the world” to stay away from energy wasting/single core languages like Xojo…
6 Likes
When I began with Xojo (RealBasic at this time) I didn’t know about thread and I used App.DoEvents. I changed all and removed all App.DoEvents and rewrote my code using thread (or timer). I’m a hobbyst and at the moment I don’t need multithreads as I didn’t need thread years ago. But I may need them in the future. Xojo needs professionals developpers to ameliorate itself, even if the large part of hobbyst (like me) are happy with Xojo like it is.
I’m the first one to say that I’d rather have a processor with less cores, but faster cores so that EVERYTHING is faster, not just select applications for specific tasks. However, Apple rarely do what I want them to do, so we now have processors with dozens of cores.
Concurrency isn’t just about improving performance of a single task. It is also about literally doing multiple things at once, and as @Björn_Eiríksson mentioned, it’s also about improving energy usage of your application, as you can schedule things to run on the efficiency cores reducing your application’s energy usage.
Many call backs from the macOS now come in on pre-emptive threads, which means workarounds as you CANNOT use the Xojo framework when this happens. Yet with other languages handling these callbacks, is no different than handling callbacks on the main thread. This makes Xojo more difficult to use and more difficult to recommend, which doesn’t help their reputation. Not to mention this is only going to get worse over time.
5 Likes