You don’t have to worry about the framework being thread safe as the helper and main application run as completely separate processes with their own memory space. You can use any data in either program in the same way you always have. The upside to this way of solving the problem is you can design and implement the main application and the helpers independently and use the debugger to debug each independently. The main application and the helpers can communicate in any one of several ways: IPCSockets, TCPSockets, UDPSockets, XML, files, or just about any other way you can dream of. The design is to create a main application (GUI or not) and use other helper applications to run separate tasks. There’s been a way to do this for as long as Xojo has supported building console applications.
Xojo export xml software#
The end goal is to use all cores and thereby make your software more responsive, faster, or able to handle more data, or do more things all at the same time. It’s just not simple or easy to use the way most of Xojo is designed to be. That’s very different than what you have to do today and a lot more work. This would mean protecting any globals and pretty much anything that is not local to the method or the thread being executed. But you have to protect every place you might set a value that could be shared by many threads. The Xojo language already has functions like mutex and semaphores that help you make a multi-threaded program. We have had to go to a lot of extra work just to make the threads you have today work without causing problems. If you access something from a pre-emptive thread and that something is not thread-safe, there’s a very good chance your application is going to crash. Much of the framework would need updating to be thread safe and your application’s user interface is not thread safe on any platform because the operating systems themselves don’t have thread-safe user interface code. Some languages, like Java, have language features built in to them to try and help make this less work, but it is still hard to get right and very hard to debug when you don’t. It’s hard for you, the developer, to work with preemptive threads. Let’s look at why the current threads are not preemptive. Just make threads preemptive (so that they will then run on any available core) and voila! Unfortunately, it’s not that simple. It’s been suggested that this should be easy to do.
We get a lot of requests for preemptive threads so that people can take advantage of multiple cores. If you have a lot of data to process, large images to manipulate or other things that could happen in the background, it would seem that with a multi-core machine you could do this faster “if only Xojo would make threads preemptive”. With today’s multi-core CPU’s it seems that an application made with Xojo running on a single core is somewhat restricting.
0 kommentar(er)
