I had a method, called by a timer action, that took up to 5 secs to process.
So I placed the long running code in a separate thread. There’s a new thread instance created every time.
I created myThread subclassing a Thread, passing a parameter in the constructor and holding a few properties.
The code is really simple:
Dim myT As myThread
myT = new myThread(param)
myT.Run
The long processing is placed in the Run event of the thread.
I’m testing and see that it takes up to 5 secs just to perform these few lines (create the new thread instance and perform thread.run).
Like the thread is not running in background. No difference with a direct method call.
I guess I’m missing something obvious. What’s wrong ?
a thread doesn’t make it faster.
It only allows you to keep the main thread responsive to user input.
And only that if you use thread friendly methods.
I know this perfectly.
Maybe my explanation isn’t clear.
The problem is that creating the thread and just performing thread.run takes 5 seconds.
I’m still expecting the 5 seconds, but this 5 secs processing should happens inside the new thread.
Here it seems the app hangs as long as the thread run event has not finished.
I’m not sure what you call “thread friendly methods” but inside the thread’s run event I’m just connecting to a ENetServer (Einhugur plugin).
ENet by nature will not hang your application since you control its flow and times with the ENet’s Poll commands, thats part of the whole concept of ENet. You should not even need a thread to run it, usually one controls the poll command just with a timer and the applications will not hang.
If you do put in in thread then the thread needs to own the whole thing and control the poll command.
Your post here though does not include much to go on what or how your thread is actually doing things.
Ok so been reading it over and over again to try to make some sort of answer that makes sense.
For individual commands then a Xojo thread is not going to stop anything from hanging since a Xojo thread is not a real thread, so anything under the hood in the OS or protocol layer is going to hang it for sure. Only a real thread would prevent such.
For ENet then healthy control of the Poll on sever and client side is usually your friend to make things run smooth.
If there is actual good actual case where hanging cannot be prevented then we could look into making Async connect method (assuming its the Connect method your having trouble with ?) that under the hood would use actual OS thread.
ENET was designed with thread safeness in mind (99%).
That would be awesome, even more running on a separate thread and avoid Polling it making it really async. But I don’t know if that’s plausible in Xojo now. Polling ENET within Xojo makes it slow and would be perfect to run it on a different thead and communicate to the main Xojo thread via Events. (No Polling)
I think I need to give more details about my apps.
On one side I have console apps (multiple instances running on different servers) running background tasks, defined as ENet servers and broadcasting informations once peers are connected. These apps are running fine.
These Enet servers are not always active, thus not always listening for clients.
On the other side I’d like to have client desktop apps, ENet Clients, connecting to one or more ENet servers.
The users can select which servers they want to connect to.
When the servers are active everything is smooth. When a server is not active, the server.connect takes a few seconds before returning a false value. At this point the app freeze, hence my idea to put the server.connect for each server in a different thread.
But the app freeze on server.connect.
My problem is not that server.connect takes a few seconds but rather that the app is frozen while doing so.
Running the ENetClientTest sample app from Einhugur (does not use threads) when the ENetServer is not listening illustrate this.
Just bit off-topic question: Would if be possible to create ENET plugin running on a different thread and with the already bilt-in packet class, made a PacketReceive event where no polling in need within Xojo? Pure Async in Connect/Received, etc.
I’m gona see about just creating general OS Thread class for those that are brave and know what their doing then people can do what they want with any part of the ENET. Thats probably the first easy step.
Then to maybe add ConnectAsync which has just the connect method threaded for those that needed it easy and just the Connect to be threaded.
