QTcpServer limit for incoming connections

[wysota]

Why do you need more than 280 threads or 1000 connections opened at the same time? You'll get a huge overhead unless your machine has dozens of processors.

[mdecandia]

Why do you need more than 280 threads or 1000 connections opened at the same time? You'll get a huge overhead unless your machine has dozens of processors.

I don't need 280 simultaneous thread: the problem is that QTCPserver doesn't close that as faster as incoming request rate.
The threads are deleted from deleteLater() slot, called by

connect(thread, SIGNAL(finished()), thread, SLOT(deleteLater()))

but it's not done immediately and finished threads (but not closed) remain opened.

Is there someway to delete immediately QThread object when it finishes his run() method? I can't call delete() inside the object and I can't connect finished() signal to external slot that runs delete(thread) because I can't pass object pointer to him. There's a way to know the pointer of the object that emits the signal from the called slot?


Thanks

[marcel]

Yes.
From the deleteLater() slot emit another signal, for ex threadHandle( QThread* ), which is connected to the object that created the thread.
You can delete it from there, safely, because deleteLater will have exited when the slot in the creator object is executed( queued connection ).

Regards

[wysota]

I don't need 280 simultaneous thread: the problem is that QTCPserver doesn't close that as faster as incoming request rate.

Maybe you're starving the event loop?

Is there someway to delete immediately QThread object when it finishes his run() method? I can't call delete() inside the object and I can't connect finished() signal to external slot that runs delete(thread) because I can't pass object pointer to him. There's a way to know the pointer of the object that emits the signal from the called slot?

How about reusing the threads instead of creating new ones? Create a pool of threads assign them new tasks when they finish the previous ones. If the number of requests exceed the number of idle threads, queue requests. If the request queue is empty, put a thread to sleep using a wait condition.

[Bitto]

Like Wysota says, it sounds like you're replacing one performance problem by another. Firstly, even with native socket code no single machine can efficiently handle more than a few hundred connections. Secondly, threads don't make your code faster unless you have as many processors. The only reason to add as many threads as you're trying to here, is it you want each of them to not block another. Or maybe you really think threads make things faster ;-).

For networking code, it rarely makes any sense to have more than a couple of persistent extra threads next to your main threads. Never restart threads, that's never smart from a performance standpoint. Keep them running. And for thousands of connections, hey, hardware is cheap. Every system that handles that many connections does it by adding hardware, not by adding threads.