TCPSockets are running in their own kind of thread? Well no, they don’t !!!
I have an app here with 20+ simultaneous busy TCPSockets pulling around 120 mbps together, but according to the activity monitor (on the MAC) the number of threads that the app uses never goes above 3. So where are all those socket threads?
The whole GIU is also getting less responsive with all those active sockets running. With 5 sockets all is fine bit with 20 and more absolutely not.
I hope to someone knows an answer how to get the sockets running in their own thread.
Or at least how to handle many sockets without effecting the GUI.
Note that this is doing a simple EHLO to my personal mail server, so don’t abuse it too badly.
Before you open the project, get a way on your OS to see how many threads are running for each app - I use ActivityMonitor on the mac.
Open the project, run it, and mash the ok button a few dozen times. Note the threads climbing. Each TCPSocket runs completely inside its own thread. The sockets will connect to my mail server, say EHLO, get a response from the server, then wait 10 seconds and disconnect. As they disconnect, the threads die, so after 10 seconds the thread count should start to drop.
I just banged this up in response to your comments - it’s not particularly clean or well-documented… but it illustrates how to do it.
I just tried this with port 23 (telnet) to my router and I mashed on the ok button about 30-40 times. I barely could get the Threads past 30 before the threads came down fast. This is working well and activity monitor gives you all of the insight down to each actual threaded telnet connection. It took about 20 seconds to get from 4 threads without the app running to over 30 and back down to around 4-6 threads.
I’d be very interested what difference, if any, that made to the responsiveness or throughput of the OP’s app. You’re still using a single core for all those threads, I assume. You’re just introducing the overhead of cooperative threads. I suspect you’re going to sacrifice throughput for responsiveness.
True, but Xojo only provides cooperative threads. The OP wanted his sockets in threads, which my example provides. I am also very interested to see if this helps with his UI responsiveness and still provides high enough throughput.
If you are looking to leverage multi-core support, the current state of the art for Xojo is described in this recent blog article by @Paul Lefebvre : Take Advantage Of Your Multi-Core Processor, and is not particularly elegant or clean.
[quote=34409:@Kimball Larsen]
If you are looking to leverage multi-core support, the current state of the art for Xojo is described in this recent blog article by @Paul Lefebvre : Take Advantage Of Your Multi-Core Processor, and is not particularly elegant or clean.[/quote]
The advantage is that its much simpler to debug the helper than to try & reproduce some odd threading issue you only see once in a blue moon & you can max out RAM & cores since each helper gets its own process space.
I wonder if the OP really wants to spawn 20+ additional separate processes to be able to put his socket communication into their own environment where they can get access to more resources and not be bothered to share with all those other pesky threads.
I hope the OP tries it both ways - I’m genuinely interested to know if your typical modern computer would cope better with spawning a lot of processes or if his throughput is good enough with cooperative threads. I have some projects coming up where this may apply.
This may jump slightly off topic, but I have a console app that interrogates devices for a bunch of information. I understand console apps as having a main thread of sorts by the “Run” event. Does cooperative threading occur for a console app’s TCPSockets for every socket I instantiate?
Sockets are processed by either DoEvents or Poll. You need to call one or the other. DoEvents has the benefit of processing all the sockets at once, instead of you calling Poll on each one individually.
[quote=34346:@Andre V.]TCPSockets are running in their own kind of thread? Well no, they don’t !!!
I have an app here with 20+ simultaneous busy TCPSockets pulling around 120 mbps together, but according to the activity monitor (on the MAC) the number of threads that the app uses never goes above 3. So where are all those socket threads?[/quote]
Why would you expect them to run in their own thread? In a GUI app, the main event loop is responsible for multiplexing all of the application’s sockets and dispatching events.
What sort of tasks are you doing in the socket events? Is there a lot of CPU bound work?
They’re also processed by the event loop in a desktop and web application, so there’s no need to call DoEvents normally. The only time that DoEvents is a good idea is for the main event loop in a console application.
[quote=34417:@Kimball Larsen]I wonder if the OP really wants to spawn 20+ additional separate processes to be able to put his socket communication into their own environment where they can get access to more resources and not be bothered to share with all those other pesky threads.
I hope the OP tries it both ways - I’m genuinely interested to know if your typical modern computer would cope better with spawning a lot of processes or if his throughput is good enough with cooperative threads. I have some projects coming up where this may apply.[/quote]
IF your goal is to max out a machine multiple processes will do that - you can get all the memory & CPU that a machine has and peg the CPU meters.
And the communications running in their own process can / could mean you UI has no cooperative threads and remains quite responsive.
But it really is all about architecture and splitting things out where it makes sense
I didn’t found any differences in speed using the socket in threads or not.
The problem was the for-loop in the DataAvailable event. The loop itself was eating too much cpu resources.
Unless you run the synchronous version of Get/Post, none of the HTTPSocket is run in the thread. But if you do run synchronous, you don’t get events, just the result. The only reason to use an HTTPSocket in a thread is to run it synchronously, setting Yield to true. There are no events involved.
This is working well and activity monitor gives you all of the insight down to each actual threaded telnet connection. It took about 20 seconds to get from 4 threads without the app running to over 30 and back down to around 4-6 threads.