I have a basic understanding of threads and what they do. And a little understanding of the purpose. If you can run multiple tasks simuntanously then why not have everything run through a thread. For example, a thread for each for loop or are threads for more linear tasks? Should threads be used when making multiple API calls to controls? For example, opening a new page in a pagepanel while creating a new item in a listbox.
Thanks
Xojo threading model is cooperative instead of preemptive, therefore code is not executed simultaneously but it’s sliced by Xojo thread manager. It gives you the illusion of running in parallel, but it doesn’t.
In fact, adding more threads makes your code run slower.
You have Erlang that is designed to run code as you want, but it’s not really very user friendly and you need to have a strong knowledge of threading (locking, deadlocks, debugger hell, etc…).
There is a request (I think is ranked 7th among Top 10) for preemptive threading…
With preemptive threading, code is still not executed simultaneously as long as preemptive threads are taking shares in the same processor or core. With multi-processing, code can actually be executed in parallel, but then this option is available now, even without preemptive threading. Prreemptive threading has the advantage that pseudo-parallel code execution runs more smoothly, but it also places more restrictions on what you can do within a thread.
Agreed on single core processors. But I am talking about present processors with dual, quad, hexa cores, of course! You can set core affinity with preemptive threading, so it’s a parallel concurrent threading. Thats the thread system we used in some projects with threads running on different cores simultaneously. Something you can not achieve with a cooperative thread architecture, such as Xojo currently. I don’t see what restrictions you mean with preemptive threading…
Preemptive vs. cooperative threading is about how multiple threads are taking shares in the same processor/core. Multi-processing is something else entirely. But then you can use console apps communicating with your main app to utilise multi-processing even now. Preemptive threading isnt required for that since multi-processing isnt preemptive it is multiple processes actually executed in parallel which preemptive threading is not.
All code accessing the user interface has to be executed in the main thread. Timers are used so other threads can initiate some change in the user interface since the code in a timer will always be executed in the main thread, even when the timer was started by a different thread.
Michael I think you are mixing different concepts. Threads are Threads, and Process are Process. There are things you can do using threads that can’t be done with process withou lot of work. We are discussing threads, not processes (just executables that OS allocates as it likes, BTW). Sharing instances among process is something not very fast, has tons of overhead, needs shared memory, serialization, IPC, etc… Processes can be useful for some stuff, and Threading for others.
Yes, updating user interface has to be done in the main thread. But the code can run in an isolated thread, make the calculation and return to the main thread to just update. This is not a Xojo specific issue…
I’ve had a couple of uses for threads in the past.
The first was with a C file server. It just had a simple loop for listening for clients trying to connect and when a client connected, the handling of this client was done in a thread. This was because if I hadn’t done it this way then the server would stop listening while handling the client’s request. When the client’s download was finished the connection would be severed and the thread would be terminated.
The other was for a game I was working on (again in C). The music and sound effects in the game would be run as threads. This would mean that the music could play in the background independent of whatever was going on in the game and sound effects would also run independently. This meant that someone swinging a sword would make a swishing sound that could occur at exactly the same time as someone twanging a bow or bellowing a war cry. Without threads these sounds would have had to play sequentially (one after the other) which would be rather stupid. The sounds would also slow down the game loop because the rest of the program would have had to have waited for the sounds to finish before continuing - not at all good either.
So the short version is: threads are used when you want something to happen on its own, independently and separately, allowing the rest of the program to continue working.
I was commenting on the difference between cooperative and preemptive threading. With cooperative threads, the currently running thread has to yield so other threads get a chance to run thats what cooperative refers to. A thread wont normally yield within a loop, for example, so code executed in a loop could still monopolise the CPU. With preeemptive threading, the OS has total control over the execution of threads, and when the time allotted to one thread runs up, the OS switches to another thread. This makes the threads run more smoothly, but since the switch can happen at any one time, the developer needs to be aware of (and actively prevent) possible conflicts between threads that couldnt arise or were easily avoided with cooperative threading.
If we had multiprocessing threads (i.e. threads that you run on different CPUs or cores), even more restrictions would apply. We had to take care our threads would not accidentally try to change the same data structure, say. With console processes communication through messages, these problems could not even arise in the first place.
Anyway, these are our options with Xojo: cooperative threading within a Xojo app and multi-processing with communicating desktop and console apps. For better or for worse, preemptive threads or multi-processing threads are not.
Of course it isnt a Xojo-specific issue, but it is an issue one has to be aware of and Oliver evidently was not.
So, as Xojo 2013 Release 4.1, what can we do and how ?
(I try to syntethize Oliver original question)
And that is the reason I was explaining the preemptive threading model (that includes what you call multiprocessing threading) are not executed in parallel and why is not a good idea to have multiple thread as the cooperative threading model is just basically a non thread, but a simulation of real threading (although xojo uses threads instead of fibers recently). Threading logic and programming is difficult, and locking mechanisms must be implemented or deadlocks arrives, are a pain to debug, I already mentioned this.
Having written the C++ backend for 2 MMORPGs I have some notions about threading programming, pains and benefits. A process is not a solution for threading programming, and is absolutely not a substitute. There are some cases were you can benefit from processes, but that is not threading.
[quote=63146:@Emile Schwarz]So, as Xojo 2013 Release 4.1, what can we do and how ?
(I try to syntethize Oliver original question)[/quote]
Xojo would need to make the framework thread safe. Xojo has already locking mechanism and Xojoscript would be an ideal candidate for real threading as a beginning. Until that, you can use other languages that includes real threading (Java, Erlang, GO, etc) or sign to (Xojo: Account Login)]https://xojo.com/issue/9515]<https://xojo.com/issue/9515>[/url]
One good symptom is that xojo does not allow to update UI elements, maybe something could be in the works… But with 2013R4.1 basically the same as Release 5 or 1 in this matter…
For me Xojo does not need a multithreaded access for updating UI elements but needs a multithreaded framework for doing anything else.
One thread doing UI access to me it is an advantage not a limit.
Many activities can be carried on in parallel in an application like, for example, communication, database access…
None of these activities requires a direct access to UI elements to be completed.
Many developers conceive multithreading as a way to have “anyone can do anything to everything at any time”: this it is the true foundation for a total mess.
A real multithreading can instead produce a very efficient system where many threads are doing, each one on a single entity, a well defined set of operations.
I don’t know if Xojo will have an multithreaded framework but for me the OS scheduler it is far better than to have a scheduler embedded in the framework doing time slice using only one OS thread.
The actual thread scheduling implementation does not scale very well…
Better use the main thread than many threads and a beautiful bug hidden within a plate of spaghetti 
[quote=63108:@Amando Blasco] Sharing instances among process is something not very fast, has tons of overhead, needs shared memory, serialization, IPC, etc… Processes can be useful for some stuff, and Threading for others.
[/quote]
And all this is responsible for the majority of the bugs in preemptively threaded code
Independent cooperating processes are much safer
[quote=63146:@Emile Schwarz]So, as Xojo 2013 Release 4.1, what can we do and how ?
(I try to syntethize Oliver original question)[/quote]
Write a helper app (console app) & talk to it over some mechanism (IPC sockets are used but there are others using shared memory & other options)
Then you can start as many copies as you need & each will run with its own memory allocation
Fibres actually have limitations that mean certain aspects of the frameworks don’t work as users expect.
Hence the change
Erlang folks would dispute this and is highly scalable and parallelizable
Let’s leave Erlang apart, as it’s a different beast. I have actually read a comment written from you about process and threads in Feedback, Normal 
[quote=63200:@Norman Palardy]And all this is responsible for the majority of the bugs in preemptively threaded code
Independent cooperating processes are much safer
Well, so let’s then go back to MacOS9 were the cooperative multitasking were awesome … and let’s forget about MacOSX and it’s preemptive threading buggy model 
Now seriously… This should not be an excuse for implementing this long request. There are bugs even with the actual cooperative threading model. If those bugs were an absolutely nightmare no single language will include threading. And we are facing the opposite, having to use Processes to emulate Threading, but you know that this workaround doesn’t work in many scenarios.
Yeah, I know fiber limitations and threading is better, in sprite of being more difficult to implement than fibers.
Norman - autocorrect hates my name
Thats not quite what I was implying
The hard part is YOUR code & shared state & trying to debug it
If you’ve written things in C++ then you know its not for the faint of heart and its VERY easy to shoot yourself in the foot
[quote=63223:@Amando Blasco] Now seriously… This should not be an excuse for implementing this long request.
[/quote]
Its not THE reason we haven’t done it
The framework and runtime are not thread safe - they do use some limited shared state & that WILL probably cause bugs.
And getting rid of it and make the frameworks thread safe is rather a big job - that a limited number of people would use correctly.
[quote=63223:@Amando Blasco]There are bugs even with the actual cooperative threading model. If those bugs were an absolutely nightmare no single language will include threading. And we are facing the opposite, having to use Processes to emulate Threading, but you know that this workaround doesn’t work in many scenarios.
[/quote]
Preemptive threads & shared state are VERY hard to debug.
Been there done that & its really a pain even in languages where threads are supposed to be easier to make safe.
The requirements extend far beyond just your code being “thread safe”.
The entire framework has to be thread safe, no shared state , etc and thats a very tall order across three, soon to be 4, platforms
Cooperating processes are far simpler as they do get their own runtime, memory space etc and you can debug them independently (mostly) even in Xojo
There ARE issues doing this though as YOU have to marshall data back & forth but then you have a clean & clear separation point
Doing it automatically would be nice - but again doing so automatically is quite difficult
Can you marshall objects across this ? They’re obviously not the same instances in two separate programs but two instances that represent the same data in some way.
But it can be done on a specific application basis (and has ben very effectively by several of our users over the years - some were even written up on the success stories pages - hunt for TinRocket)
Threads were the only way to make things in the runtimes work
We are both victims with the autocorrection 
Mine liked to call me Armando, grrr…
I agree and have posted before that framework would need to be thread safe to make threading plausible. And yes, I also commented that multithreading programming is difficult, easy to make mistakes and Debug Hell as I defined. But I don’t agree that it would be used by a few. It could be a reason by a developer would choose other language over Xojo, and all languages shares the same problems related to threading… and yes, I have pulled my hair, destroyed a few keyboards, etc… but once the code doesn’t deadlock it’s worth every keyboard (I used cheap ones when dealing with this kind of coding).
I still don’t see how to emulate a fast threading in process without having to buy new keyboards to throw away, code days/weeks and until all the code marshaling code is, just to discover it goes slow as a crawl! Specially when lot’s of instances are related in the threading loop for a few millisecs…