Declares is the easiest way you can find to crash app. Wreckless user will crash it instantly there.
You should not make Xojo cheap so people have to seek other tools just because wreckless user could crash it. While other users need it to be able to grow with the tool.
And going through the framework adding exception if method is not “thread safe” is not going to work either since that is just not how things work with threading.
Non thread safe you can use in thread. Just cannot use same instance of the given object in more than one thread at once. For example if Date was not thread safe then I still could use dates in threads…two threads just could not write to same date object without setting up mutex handling to guard for it.
There is of course other kind of not thread safe, that is user interface. But that is different story, and really just same story as with current Xojo threads.
It isn’t Xojo’s responsibility, or even their mission, to make a tool that caters to the needs of every single developer and development scenario. They’ve chosen a particular subset of problems to solve with their product, just like literally every product in every market - you don’t expect your oatmeal to act as a fuel for your vehicle and you don’t try to construct a house out of pool toys.
Hi Geoff.
Trying to make the framework thread safe would be an impossible task and probably result in a much buggier and slower framework. Even Microsoft admit that the .NET class libraries are not thread safe by default.
For features like this you really need to make it the programmers responsibility to do it right. If users needed to access properties across multiple threads they could use the CriticalSection and Semaphore classes that already exist in Xojo.
I agree and I wasn’t suggesting making it thread safe just making it so that if you tried to access a part of the framework that was not, it could instead raise an exception.
The difference with declares is that you are accessing the OS, not the Xojo framework. Plugins are outside the Xojo framework as well and they too can crash but there’s a clear delineation. With preemptive threads, there would not be.
What of Ptr then? I can tell you from experience that I can make an app crash hard by misusing Ptr, and that is part of the Xojo framework.
But this is a distinction without a difference. Declare is part of the language, and I can (mis)use it to make a buggy app. There is not much Xojo can do about that, nor should they try. It’s a feature most users don’t need, but one that is vital to those that do. Those of us who use it are expected to know what we are doing to do it right. Preemptive threads are in the same category.
Given that more concurrency is where software development is heading more and more with the multiple processor core systems of today, it seems to me that is the equivalent to saying that Xojo is primarily for hobbyists or relatively simple utility apps.
If that is their primary market, then ignoring preemptive threads make sense. If their ambitions are to be significantly more then that, it would seem not a good idea for the long haul.
That would be nice but it doesn’t have to be there on day 1. It could be that most of the framework is already okay with very little need to raise exceptions but unless an effort was made to progress this it will never be known.
The current cooperative threading model should be kept as the default but having access to preemptive threads even with the risks could benefit us much more than workers can.
In fact, most experienced developers run into limitations sooner or later, preemptive threading being only one of them. I think this thread gives a clear impression. And so experienced developers will rather find they outgrew Xojo.
Threading is an advanced feature, yes! Declares are, and like Björn said it is easy to crash the IDE with a wrong declare. I do quite often. What happens? In most cases the debug build simply disappears, I find myself back in the IDE and often have to employ Apple console to find what went wrong. Because I know I work on system level, and Xojo gives me access to it but is not responsible for handling everything inside. I do not expect Xojo to have an internal declare checker that runs everything I type against the API I use to see if my code matches the API documentation. And Xojo found it sufficient to warn me like this:
Incorrect Declares, such as Declares that use an incorrect library, method, parameter or selector will crash your Xojo app. You will need to review system logs (such as Console on Mac) to see what the OS reports as the cause of the crash.
We know we can use Ptrs. We know we will never be able to use GUI elements inside a thread. We would only need a handful of basic datatypes and classes for a start, which, as it was proposed, could be added inside a new thread-safe namespace, with their superclasses being wrapped inside one of the memory management methods that have been proposed here. No need to check the whole framework against compatibility. But the option to add more classes whenever there was time to check/modify them. Would make the statement above much more valid to me.
We’re going in circles since I just said, as a user, that’s a distinction without a difference. But you didn’t address my point about Ptr at all. That’s entirely within the framework, is it not?
So Xojo Inc. could keep preemptive threading as an official unsupported feature.
But still make sure some runtime framework functions can be used on a preemptive threads, so the pro developers, who want it, can do a few things.
Doing REALLockObject and REALUnlockObject with an atomic operation to increase/decrease would help. Then check that REALnewInstance and freeing instances use mutex when adding/removing object to linked object list.
We may individually ask for more things to be adjusted to make it work better. But it could continue to work on your own risk.
First, I was mistaken about mentioning exceptions because of course, this is a compile-time issue not a runtime issue.
If we decide at some point to provide preemptive threads, we would mark the math functions in Xojo as safe and the compiler would fail to build should the thread access any other part of the framework. It would therefore have the same limitations (initially) as Christian’s plugin. Over time, if there were enough requests, we could make specific framework functions work. By work I mean you could call them and still build but if those functions are calling out to the OS and replying upon something not thread safe in the OS, they would run on the main thread and thus your preemptive thread would pause while it waits for the function to finish.
@Kem_Tekinay has mentioned a specific use case he has for needing this. I’d like to hear from others that have specific use cases. I’m not talking about theoretical ones but actual situations they are facing now.
To be completely clear, I’m not saying we would never add preemptive threads, because they are very limited we imagine the number of users needing them is equally limited which means we typically have more popular features to add ahead of them.
That sounds like an overly cautious approach and probably makes the feature dead in the water as it would take years for Xojo to enable stuff that would more than likely just work.
A better solution could be to have a special beta programme with the feature implemented with no compile time restrictions. Testers could then see what did and didn’t work with any compile time restrictions being imposed based on those results.
I doubt this would work. The framework probably isn’t structured in a way that this kind of testing would produce very useful results - the objects and functions that are exposed to us, the programmers, are probably just the tip of a large iceberg, and multi-threaded systems are notoriously difficult to debug. A function might work in one scenario and fail in another, or fail in what appears to be a completely random fashion. Discerning the signal from the noise would be quite a challenge.
Nope. I was trying to say “use the right tool for the job”. Xojo has designed a tool that is intended for a particular purpose, and this entire thread is full of people commenting on how it isn’t suitable for a different purpose, sometimes in a way that makes it sound like they think it should already be suited for it.
As Björn mentions if you want to use unsafe items you wrap the around mutexes. You just need to have a way to see the unsafe items as a warning, not a compile error. Sharing a global integer can be unsafe using i = i + 1 if another thread is calling i = i -1 and the same time. But that can be solved with mutexes.
