I’m all for true multithreading in Xojo. I don’t think I can renew my license until it has true multi-threading. I was in the middle of developing an app that would be deployed on both windows and mac and I needed multi-threading and came across the info about workers and multithreading being single core in Xojo. This brought my project to a halt. I even tried to make console apps to handle certain things, but it became too cumbersome to do this. So I had to move my project to a different language and I will be forced to make a windows version and a mac version of the app.
That being said above, I’m sure there are some good use cases for spawning separate processes vs threads. Look at Chrome and Chromium built browsers, they are both multithreaded and multi-process. They did that in order to keep tabs and such isolated without crashing the whole browser. At least that was their claim to fame in the beginning. This does use more memory in the end and resources in the end though.
Bottom line, it’s all about the use case for it. For me, doing it as a console helper app, just was not the solution I was looking for and so I moved to a different language that could handle it, and I couldn’t justify renewing my Xojo Pro license any longer.
Just throwing out my two cents on the subject. Thanks for reading!
Just so you all know this, many of the same problems & restrictions you currently have with workers would still be present with true preemptive threads.
They can’t actually talk to each other without some sort of shared memory
they definitely can’t directly access the UI because the underlying frameworks from Apple, Microsoft and Linux are largely not thread-safe
interactive debugging of preemptive thread crashes is painful in any language.
Providing workers actually does encapsulate these restrictions quite nicely and if you realize that they’re just console builds, an experienced user can very easily figure out what is and is not allowed… and multithreaded programming is definitely for experienced users. A cross-platform shared-memory protocol would be a welcome addition to the mix.
But yes, it would have been nice if the worker protocol could have at least sent back an exception stack.
Not that I’m aware of. It probably should have been implemented as some sort of Remote Procedure Call (RPC) mechanism so that errors could be sent down a different path than successful methods, but the reality is that even if you do get that stack, the paths will probably be not be very helpful as your code is copied into a console app at build time. that’s the stack you’d get back so Xojo might need to do some cleanup for it to make any sense.
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.
Having said that, if you have situations where preemptive threads are the only solution, please comment on the issue so we have that all in one place. Ultimately we want you to be successful and in some cases we may be able to help with a solution you can implement now. Also, if there are features you’d like to see added to the Worker class, make sure you make feature requests for them of course.
Microsoft did end up making libraries that were thread safe without updating the original non-thread-safe libraries. There could be a situation where Xojo could make some of the common things that would be thread safe.
Most of the multi-threading items that I use are done when communicating with other systems. Like the backup software I’m writing, i spawn threads to do the backups. Now, that is not very CPU intensive and the worker class could probably handle that just fine, but there have been other things like compiling reports and such that was cpu intensive that I have spawned as a separate thread that would then report back once it’s completed and I could notify the user in the app.
I will say threading in .NET is easy compared to other apps, but not every object needs to be a thread safe object when using multithreaded as long as you keep track of what you’re using, but even then there are “lock” methods that can be used to prevent deadlocking and such.
That could be something that could even be implemented in Xojo with threads to prevent certain non-thread safe objects from having issues.
I would love to see those workers in web and in console apps as well, so far they do the job but to implement the same functionality on a console app would be quite some work I guess
This design is good for security and stability, which is why web browsers use this model. If a process gets compromised, it’s damage is limited. If the process crashes or freezes it doesn’t take down the entire application with it.
However for data processing, the overheads and additional complexity are a negative for Xojo.
There are two main cases which are better serviced by preemptive threading.
Speeding up processing of large amounts of data.
Performing background tasks, utilizing data from the main thread, while including the ability to run these less important tasks on the efficiency cores.
The benefits of such a system may not be realized until it’s actually been done, I honestly thought it was going to be really difficult in Objective-C with GCD (especially as I’m not a Objective-C programmer), it left me shocked at how easy it actually was to gain the full benefit, and made the current Xojo design look incredibly cumbersome.
I’ve beat this horse a number of times over the years, I do hope it’s taken seriously this time. It would be good for Xojo to put some attention on the shell inefficiencies that I’ve documented and allow for workers or processes to use efficiency cores on modern Macs.
While I agree workers (or even better custom classes running inside an NSTask as Sam proposed) are often a good solution for longer running concurrent operations and they are often used today (hello Adobe! Often spawning dozens of AcroHelpers …), the complete thread inability of the Xojo framework makes one turn to incredible complex solutions once we are trying to use one of the many system API calls – especially on Apple’s systems – returning asynchronously on a background thread. Xojo object locking makes it impossible to use anything Xojo beyond shared properties, and even that is no simple task to build. Apple’s APIs are implementing more and more Block callbacks. Xojo is preventing their usage currently, or making a difficult task a full expert thing.
It would be enormously helpful to have at least the most common Xojo classes available in a threadsafe manner. Of course there are limitations to background threads, but that is true for every thread. Or did someone NOT manage to create a ThreadAccessingUIException at some place in his career?
I’d really prefer to have the option to “enter at own risk” instead of the IDE telling me “it’s too dangerous” and forbidding access to OS’ features available for many years. So please, yes, if ever possible add threading compatibility.
from from i little understand here,
instead of using thhread / workers
is this possible like said, to make an xojo "helper "console app that manage url connections and write data locally ? then desktop app behave like front end of the “backend” helper ?
Well that’s news to me. There’s me happily prototyping something in desktop with the option of moving the code to console for server side processing with workers. Total waste of time, unreal. Back to the drawing board.
i was there before you, still trying to skip the UI and do all processing on console but so far it is painful