QSharedPointer and... self reference?

Dariusz · wrote on 17 May 2021, 18:33

@Christian-Ehrlicher so I can emit as QPointer<objectX>(this) to wrap self into QPointer? Interesting thank you! This could work I think o.o

Christian Ehrlicher · wrote on 17 May 2021, 18:35

Why would you emit yourself instead using sender()?

/edit: ah - thread boundaries... still don't see why the pointer should be invalid on the receiver side.

SGaist · 17 May 2021, 18:39

You know that at some points you might be doing too much threading ?

The validation part being pushed on a stack and handled by a different thread while the original might be dying in between looks a bit strange. Can you explain why do you need to delegate credential validation to a different thread ? How long do you expect that validation to take ?

Christian Ehrlicher · S SGaist 17 May 2021, 18:37

@SGaist exactly my impression - the workflow is wrong. Normally a socket stays in it's thread and all the work is done there. Not one socket in many threads. This is just slow due to the thread context switches and cries for problems as we can see here.

Dariusz · 18 May 2021, 10:36

@SGaist Say I get 30-40k connections, it takes about 800ms to decrypt the packet, even when I run 50 threads that is 700 connections per thread that's 700ms per login packet etc etc. With so much data it takes few seconds to get it "rolling" and validation can take some time too. As he has to check login attempts/etc/etc flag bad connections/etc/etc.

Christian Ehrlicher · 17 May 2021, 18:54

As I already said - don't move the sockets around but put them into different worker threads which are responsible for the handling. Load-balacing is not easy that's why apache or any other webserver exists.

Dariusz · wrote on 17 May 2021, 18:54

@Christian-Ehrlicher yee... I think we miss understood each other. I have a set of threads and each thread has a set of sockets. So its not 1 socket in many threads. its many threads for many sockets. This is my profile snapshot >

The selected are is clean up function that removed dead sockets, if I can have them as smart pointers I no longer have to check their live/clean them up.

The top "wide" pink are - that is busy are socket jobs that I perform when new client connects - this is about 20k connection test. the sockets down below are pragma omp sockets that perform clean notification. That notification could be removed/optimized further if I can use shared ptrs and remove the wait times entirely.

In general its a training exercise to see if I can build efficient server/socket system using many threads. I've already learned A LOT about threads and connections using different queued/direct connections methods.

The entire width is about 80 seconds, 40s of which are 2 mutex wait events for clean ups.

Christian Ehrlicher · wrote on 17 May 2021, 18:59

I only said that in a webserver-concept you do not move the sockets around in the threads but assign a socket to a dedicated thread. Everything else will be too slow. Even using Qt for such a task is imho a too big overhead for 30k sockets.

kshegunov · wrote on 17 May 2021, 22:16

@Christian-Ehrlicher said in QSharedPointer and... self reference?:

Don't put QObjects into QSharedPointers when you use parent/child relationships.

Or ever, really. QObjects are never "shared", and they already have the "weak" pointer machinery facilitating QPointer. If one ever does (which one never should), it's imperative that the deleter is calling deleteLater.

kshegunov · wrote on 18 May 2021, 10:36

@Dariusz said in QSharedPointer and... self reference?:

@SGaist Say I get 30-40k connections, it takes about 800ms to decrypt the packet, even when I run 50 threads that is 700 connections per thread that's 700ms per login packet etc etc.

Btw, do you have a 50 core machine? If you don't, then just don't.
Threads don't materialize performance out of thin air!

Simply run a few threads instead of wasting all the time in context switches.