QSharedPointer and... self reference?
-
@Dariusz said in QSharedPointer and... self reference?:
I'm just looking for a way to have "valid" pointer.
When do you need this 'valid pointer'?
-
Well say a client connects, a log/ credentials/ information is required so the credential/connection manager waits for them. Say it received them push them to stack for processing in another thread and when other thread-validator get to it will validate the details. In meantime, the client can disconnect and die off. Now atm I send data back to server and use it as "validator" if object still exists(socket/client), but it would be much more efficient to just do... toStrongRef().isValid() to see if its ok to send data to it...if I had a weakref of it/ sharedPtr. could save me a mutex in logic and speed up the process by a lot. I have then "self" governing objects without the need for manager oversight.
-
-
@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
-
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.
-
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 ?
Interested in AI ? www.idiap.ch
Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct -
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 ?
@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.
-
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 ?
@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.
-
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.
-
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.
@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.
-
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.
-
Don't put QObjects into QSharedPointers when you use parent/child relationships.
I don't see what's wrong using a raw pointer here.
@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 facilitatingQPointer. If one ever does (which one never should), it's imperative that the deleter is callingdeleteLater. -
@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.
@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.
