I know this conversation has been beaten to death; however I came to the realization that it will probably be needed in the near future.
With Mojave, Apple demonstrated Marzipan; which is basically an iPad application running on the macOS. Apple have suggested that starting next year, developers will be able to port their iPad applications to the Mac very easily. Which in turn will probably make macOS developers consider building iPad applications, so that they can run on the Mac and an iPad.
At some point also in the future; it’s pretty much expected that Apple will ship some computers running their custom ARM chips, my guess is the only way to target these Macs will be via iPad applications.
Which leads me to the multi-core threading. Currently Xojo doesn’t support preemptive threads, so to make a Xojo compliant application that can utilize more than one core, we must create “Helper” applications. Sadly; it’s my understanding that iOS doesn’t permit plugins or external executables (external from the main executable) so this model that does currently work, will not in the future.
Both Thomas and Christian has demonstrated that it’s currently technically possible to create an application in Xojo that can use preemptive threads, I seem to recall the complication comes from a) Xojo wasn’t designed to support it and b) property locking and such.
So I’d like to open a discussion and see if we can’t put our heads together to come up with ideas that would provide relatively painless mechanisms for Xojo to implement; that would then enable preemptive threading. Although I do realize that the percentage of people who could benefit from preemptive threading may be minimal.
Perhaps what might help others (and myself). is a more complete understanding of what Preemptive Threading is, how is might be used in the real world, and what benefits some applications might gain from its use. And while we’re at it… how is this the same (or different) from “Grand Central Dispatch” that is native to iOS now? [I don’t know if macOS has a counterpart or not, although I would assume it does]
My understanding is the “GCD” does what you described in #2… creates a thread and hands it to the next available CPU core, allowing it to run in parallel with the main thread
Grand Central Dispatch is Apple’s fancy name for the controller of preemptive threading in the macOS.
[quote=415757:@Karen Atkocius]If I under stand it, In theory It would allow you to:
use more than one core with much less overhead than with helper apps
allow the use of multiple cores for an app on a mobile device as iOS does not allow helper apps
He wants the framework to support that transparently at our level so teh same code that uses multiple cores can be run in Mobile Desktop and web apps[/quote]
Correct.
In my current situation, I have an application that uses various Apple API, these are synchronous tasks (but preemptive safe according to the Apple docs). Which means that using them in Xojo, even in the current Xojo thread, they lock-up the application while they work (because the current threading model is co-operative). Some of the tasks can take as long as 30 seconds (on my machine, with the test data that I have, could be longer on other machines with other data), which is just long enough for a user to believe that my application has frozen (no progress is reported and the progress wheel can stutter or stop going round).
Moving these same tasks to a helper application, keeps the interface responsive while they complete (progress wheels, even custom one’s can animate smoothly). It’s such a little thing, but it is expected.
If Xojo does adopt preemptive threading, in theory it should enable the following.
Make development easier as it can be done in a single project.
Make it easier to port this application to iOS (and potentially other platforms).
By supporting iOS applications, should enable the application to run in future versions of the macOS that are just iOS with a different GUI (Although this point is pure speculation).
Reduce the complication barrier that might preventing others from adopting threads correctly.
Make development easier as it can be done in a single project.
Make it easier to port this application to iOS (and potentially other platforms).
By supporting iOS applications, should enable the application to run in future versions of the macOS that are just iOS with a different GUI (Although this point is pure speculation).
Reduce the complication barrier that might preventing others from adopting threads correctly.
I know it’s a lot to ask for just me.[/quote]
I am sure Xojo inc would love to be able to provide that… It would give them huge competitive advantage… but from what was said in the past a LOT of stuff under the hood would need to be rewritten… so I doubt it will happen
Just remember that in the same way that threads in Xojo right now must be isolated from UI access, preemptive threads must be isolated from everything that is not thread safe… in other words the entire Xojo framework.
At best a preemptive thread would only be able to get or set the values of properties that are non-object intrinsic types (for the most part the ones you dont need Dim to initialize) the best of which would be integers and pointers and do nothing else because the framework itself isnt thread-safe which is kinda useless and down right impossible to explain to users.
What you can do is get callbacks from the OS that are not on the main thread and then stuff some data into an intrinsic type to be picked up by the xojo app similar to how tasks work. But that only works because the code that the OS is running which ultimately culminates in the callback is thread-safe, not the Xojo code.
hmmm… Please forgive me if I’ve misunderstood, but what you’re saying is that I wouldn’t be able to use any Framework functions. So for arguments sake, lets assume my thread opens an image, and applies some processing to it and creates a resulting image. This would have be done 100% in declares to the OS API to perform these operations and I wouldn’t be able to exchange objects between the main application and the thread?
If I understood that correctly; I could in theory create a block of shared memory that contains a ptr to a NSDictionary, which would contain a NSURL and various NSObjects for handling the description of processing. Then on completion, the thread could also post to the shared memory a ptr containing the CGImage? Not worrying about memory management for the moment.
I use this when dealing blocks that fire on a different thread; but the function I need to call doesn’t support blocks, as far as I can see, I am meant to call this function from a thread I created. Interestingly enough the documentation does say that I can’t use the same objects inside of the thread as I use outside, I have to explicitly clone them in the thread before use.
To be honest: I was a bit surprised about this thread because we did have this discussion a few times without much result. But so says Sam as OP, and if the purpose of this new thread is to collect the data:
Not only that. You can create NSDictionaries or NSArrays (or whatever) via declare inside the thread and pass them to a shared Xojo ptr or even forward them to a method installed in a custom NSObject subclass with PerformSelectorOnMainThread.
And Thomas has proven that you can do much more, even on Xojo level, in his MBS conference session. Also in the aforementioned opposite direction, when creating blocks by code that will or could be called from the system on a background thread.
I think it has been stated that this is becoming more and more important because Apple prefers them over class delegates like in the old days. Understandable because, hey, parallel computing! And if it were not for the background handling problems, blocks are way more faster to create in Xojo than hacking a delegate class.
I recently ran into a similar problem like Sam when working on a clients project which is used to address several devices. The one I was trying to control on Windows uses the same “Register a thread to wait for an event”-approach, and of course waiting will stall Xojos thread scheduler. While I could work around most of this by time-slicing the events via their timeout thanks to an answer received here (but sadly not the main function which, when run on a Xojo thread, produces way less samples than the instruments manufacturers own solution), the only clean solution would have been to incorporate all that stuff into a (or several) console app(s). The customers reaction was to consider Xojo a worse solution for his project because many other modern languages do not have this limitation. I am afraid that he is not fully wrong. Thread handling currently is a minus point on Xojos side in the programming languages comparison chart. If there would even be an internal timeout timer that would force the thread scheduler to yield
We all know Xojo has some very ambitious plans for future releases. I always forget the name of the programming law “It will always take longer than you think, even if you consider that it will take longer”, so pressing another topic to priority on the wish list could be overwhelming. Anyway, I sincerely hope this topic will gain more priority once the announced priorities are done. Even if it would mean some bigger limitations. We are used to be cautious when using a thread, so ok, have more limitations when using a background one. Should even be possible to include a check that issues a compiler error when you try to address a Xojo instance property from inside a preemptive thread for example. Thomas has proven that a lot of things can be done, and having such a solution available natively (I still did not succeed in changing his blocks example into something that can be used as easily as Joe Ranieris ObjC Blocks plugin) would be a great relief and alleviate one big current disadvantage. There is nothing really RADish in preemptive thread handling currently.
Right, but I havent looked at declares to see if they render any non-thread safe code, and they might. And youd still need to be very careful because there are portions of the Apple framework code which isnt declared thread safe.
Basically it’s a bit of compiled JavaScript code which exectutes on a preemptive thread, but has very strict rules about communication back & forth with the main thread - basically, you can only pass blocks of data using messages, and do some other things (such as XMLHTTP requests).
I wonder if there could be some sort of limited mode of Xojoscript (or full-on Xojo) that worked the same way?
Basically it’s a bit of compiled JavaScript code which exectutes on a preemptive thread, but has very strict rules about communication back & forth with the main thread - basically, you can only pass blocks of data using messages, and do some other things (such as XMLHTTP requests).
I wonder if there could be some sort of limited mode of Xojoscript (or full-on Xojo) that worked the same way?[/quote]
I really wish Xojo would throw us a bone and provide some kind of access to a better concurrency model. Co-operative threading works great most of the time but being stuck on one core is a big limit due to too many things which block.
Helper apps do have their place but they are difficult to manage and overkill for many situations. They also dont work on iOS and more than likely Android. The other solution of using preemptive threads in a plugin works really well but you arent developing in Xojo anymore and there also isnt a solution for mobile.
My understanding is that the problem seems to be that the Xojo framework isnt thread safe which makes any improvement impossible. Running a XojoScript could be a first step but unless you have access to the context object (which raises the framework thread safety issue again) you probably couldnt do much.
The Web Worker model is interesting as they have solved the problem with concurrent access to data. However, it does have its own problems as you have to clone data back and forth and split data up to parallise tasks. This can be slow and lead to memory management issues for large amounts of data such as a 100MB image. There are other ways to solve concurrent access to data but probably requires new features within the language.
I do fear that we will be stuck on a single core forever. The subject has come up several times in the 12 years I have been using RB / Xojo and the response from Xojo Inc. has never made me feel warm and fuzzy.