I would say more or less all Apps nowadays benefit from native threads. The way things have been put down by CPU and OS developers then your supposed to spawn thread for just simple thing like update check. Thats how you archive max efficiency and not using just one UI thread and timers and what not.
7 Likes
Nothing ridiculous about it. Who’s going to want to use a tool that promises preemptive threading that is so limited and fraught with risk? Languages need to be very solid in their core features or people move on. For goodness sake, people (justifiably) give Xojo guff about how it handles doubles - imagine the uproar as people upgrade to get the new preemptive threading feature, only to discover that it can’t use most of the framework, or that it crashes unpredictably when they do?
Precisely. Modern CPUs have both performance and efficiency cores. There’s no way for the system to know how to distribute tasks without native / preemptive threads. An update check doesn’t need to happen on a performance core.
4 Likes
That’s not really true, at least with regard to spinning up console apps instead of preemptive threads. On the Mac, a process can identify itself as “low priority” and the OS will schedule it on an efficiency core.
As has been mentioned above then you do not need Object to be “thread safe” to use it in thread. 99% of what you use normally only has to run in one thread. This means that you can use everything that is not UI basically. (No matter if its thread safe or not).
Thread safe means its concurrent object basically and can be used in more than one thread at once.
For this same reason then most objects in other frameworks (.NET for example) are not “thread safe” since thread safety comes at speed cost and is not needed for most objects.
Only thing that is needed to make all this work, is to fix the Xojo memory manager. (since that one is by definition shared among all threads). So mutexes need to be added there.
5 Likes
You’ve explained this a couple of times, it looks like Xojo should know that it’s simpler (to go a step forward) than it sounds. We by now all know objects shared amongst threads cause issues (in all languages)
I hope in this that Xojo does do something towards multi-core threads so that the systems (OS) can keep the load down and process spread up. There is no argument that can say single core process (like xojo) is the way to go, why whould the OS’s have so many cores otherwise?
Would it be possible to have access to thread safe plugins classes, einhugur and mbs?
So if we wanted to do image processing using their classes on these threads. Passing data into and out of threads via shared memory or strings would be easy enough.
You saw my other forum post here? Preemptive Threading
You may be able to work on a few things.
And this could also include calling plugin functions, which you know of don’t create Xojo objects.
1 Like
Well, on my MBP there must be hundreds of processes running (I wish Activity Monitor gave an easy count!) so having multiple cores in the CPU still has an advantage even if any given process only ran on a single core.
Not downplaying here the potential advantages of pre-emptive threads for tasks in a Xojo application, just saying there are advantages to multi-core CPUs which do not require a given application to be multiple core.
To answer that question then, getting access to it is no problem per see. (Like to our Multicore framework or our Task framework)
But the limitations are just to severe at t he moment when called from Xojo, basically 100% same as Christian lists above. (This is due to the Xojo Centralized memory manager that needs fix).
Plugins can though sort of do threading amongs them selfs like for example Christian could create TypeLib task. (I have API for that somewhere)
1 Like
I saw, that. It might just be a little too limited for anything i can use it for right now. I have a lot of parts of my app which could use threads. We currently use helper apps to load images off disk and resize them as well as applying retouching effects from an external library. But generating pictures for rendering in the GUI would be the most helpful. Eg we have to render up to 30 composite images to be shown on screen. Doing this on other threads would improve user experience a lot. Even being able to show low res version right away and then generate high res version in background etc. This would require more of the Xojo framework, pictures etc. But most of this is done in your plugins.
I’m very used to threaded apps, Java , Dot Net, and really miss this functionality.
1 Like
Well, true. I meant in the same process, but you’re right.
For image processing, you can use concurrency now within Xojo. For our HDR application, I abandoned the Xojo picture class and went direct to CGImage. CGBitmapContext allows you to get at the RAW pixel data. I then wrote a custom plugin that uses Apple’s GCD and processes the pixels in 1/7th of the time (on an 8-core system). As I keep mentioning, I have very little experience with writing Obj-C, but it took me a morning to get it to work, then I added support for more bitdepths and pixel orders over the next few days.
Depending on what kind of image editing you’re doing, you can use Apple’s CoreImage (soon to be deprecated I am sure) and write custom shaders that execute on the GPU. However CoreImage, easy to get started with, has lots of gotchyas and can lead to very frustrating experiences, especially across multiple OS versions and even multiple hardware.
Otherwise, if you want to keep it simple, use @Björn_Eiríksson image plugin and the Xojo picture object.
@Geoff i honestly think this thumbs up system just won’t get the “thumbs ups” from the developers that actually need this. Perhaps it’s best to promote a list of “most requested” every month or so (per release) where these can be voted for. In this way it’s presented to everyone to “thumbs up” instead of every dev having to search for each individual issue/feature request. I could swear this “multicore” came up so many times it should already have become part of xojo, since a worker is slow it’s not true “multicore” (more like sub processing) as how other dev platforms/frameworks manage this. And no it’s not “too complex for everyone” only those who want to use the true power much learn to use it. Xojo is very powerful by “once click to compile” but that’s kinda all, since it begins to get behind where the world is moving to.
1 Like
The thumbs up system doesn’t seem to work at all. I don’t know what’s a good number, but I’m lucky to see a case with more than 1. I have a simple case with 4 and a more complex one with 6, but no reaction or movement from Xojo on either. No system is perfect, but this one doesn’t seem to have any influence.
7 Likes
If you sort by “Priority” youll probably notice why nothing is coming trough (or seems to).
The “Pro Plus” label is upped above everything even if the date is later or older than already placed cases. It seems there is “0-priority” to cases of Pro and lower these days ? Or some of xojo can clarify how this works?
Well, Xojo Inc. doesn’t just implement what gets a lot of votes. They pick things …
- that they need themselves
- that some bigger customer pays for
- that marketing needs for promoting the product
- that an engineer likes to spend time on
Oh, that looks just like the criteria that I use for my plugins 
There are plenty of nice things with >10 votes, that didn’t get attention.
So none of the listed items is “what the customer requests” basicly the way we can see it. There is probably a lot going on under the hood but again, we cannot “see or understand where to get votes” nor “how the voting system would help a customer in any way”. (basicly on most issues there is just 0-response)
1 Like
Well, if Xojo inc decides that they could need it themselves for the compiler or IDE stuff, then it may be possible.
Also they could decide that it would be good for marketing to start an initiative to please Pro customers and do it.
In any case it could be started simply with a limited set of framework parts.
This is exactly what I’ve been doing since the RS days. The exec scheduler can then run each shelled process on a separate core/thread.