I tried to instantiate (with a for next loop) 1000 threads, in the run of each thread the code opens a db connection (mysql) and writes a record to a table, after writing it adds a 1 to a public value of the same thread. I notice that the threads are all instantiated but the execution of the code stops 150th thread, the remaining 850 threads do not execute the code contained in their run, can someone help me?
First I’d like to know what happens if you try to open 1000 terminals and do the same using CURL for example. And then again do the same multiplied by the count of your CPU Cores please.
Or in other words, why? 
Assuming you are looking for speed…
If it worked and you were able to start 1000 threads and write a record to a table in each one, it would probably be slower than running a loop 1000 times and writing a record in each iteration.
for those who want to understand why I would like to use threads and having a number of instances greater than 150 I am going to outline the scenario.
I have a socket server that instantiates for each request it receives a tcp socket that once listening and once it receives data must perform a fairly long sequence of activities on various tables in a database.
if I encapsulate the processing of the data received in the DataArrival event (or in the modules it instantiates) the result is that I lose many transmissions or even the system working on the same DB connection, it suffers monstrous slowdowns or and some queries or inserts are aborted and an error is thrown from the data source saying there are other queries being processed. Threads with their own connection to the db would resolve as they would work not sequentially but independently. However, in fact the thing I don’t understand is because if I instantiate 1000 threads the first 150 work very well while from 151 threads onwards, the run code is not executed
I don’t know the inner workings of Xojo, but it could be possible that 1000 threads is just too many. Technically, it should work. But it seems to be failing at 151, which is also a mystery. Usually, in a situation like this I just try something else. For example, maybe you could dump everything to queue (array, dictionary, etc) and have a timer periodically check the queue and write to the db. Then again, maybe I don’t understand the technical reasons behind your current implementation.
1 Like
Well, don’t do this. Instead, suspend your thread and have the DataArrival event resume your thread. The thread then does a ReadAll and processes the new data, taking as much time as it needs. Once it’s finished processing it can suspend itself again.
1 Like
Have you tried splitting up the thread count into multiple workers so that you are definitely taking advantage of all the total number of CPU cores? 8 cores running 125 threads each?
1 Like
ok the problem was in mysql configurations !
in my.ini the max connetions default value is 151 
max_connections = 151;
3 Likes
How many times have I bumped into that config value!
2 Likes
Threads in Xojo are co-operative, which means that they’re sharing one processor core ONLY.
Instead, I would recommend implementing a task list. Then launch a helper, which takes the first task from the list and operates on it.
When the helper has completed, then launch a new instance and give it the next task.
Now using declares or plugins, figure out how many cores the computer has. And then launch coreCount-1 instances of the helpers.
Every time one finishes, launch another instance and give it the next task.
Repeat until the task list is empty.
This should give you maximum performance, while at the same time efficiently managing “tasks”. Xojo has a “worker” class which does this when the application is built (but uses threads while debugging).
3 Likes
The most obvious answer: “Dont use a spoon if you need an excavator”
Now, if you really like the spoon, you have to shovel slowly doing what Sam said.
Best mark the post solved then, as this message is now halfway down the list of replies and people may read the first and last messages then spend needless time looking… 
3 Likes