QSharedPointer and... self reference?

Dariusz

Hey

Say I have a signal like

class objectX{
public:
      objectX();
      ~objectX();
Q_SIGNALS:
    void newData(const QString&data,const int index,QSharedPointer<objectX>sender)
}

How can I properly send "self" from that object but without having a member containing QSharedPointer of self and then blocking auto-deletion of the object?

SGaist

Hi,

Why do you need to send the sender along the signal ?

Dariusz

Well... I suppose I could use sender() to get it on the other side... but lets say I cant and I connect many objects with that signal to one object... so I need to know which object has send the signal... I could send object id for example and some more data but then I have to search container for it... so I wonder what is a better way of doing it...

Christian Ehrlicher

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

I suppose I could use sender() to get it on the other side... but lets say I cant and I connect many objects with that signal to one object... so I need to know which object has send the signal.

so why not use sender()? Or a simple plain pointer?

Dariusz

@Christian-Ehrlicher Well sender is going to return pointer, not QSharedPtr is it? Using raw pointer will mess up logic then as I will end up with raw ptr and shared ptr being used in the app so I'd rather avoid that.

SGaist

Can you explain the goal of your design ?
It's quite surprising that you need some smart pointer to handle the lifetime of a reference to the sender of a signal.

Christian Ehrlicher

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

I don't see what's wrong using a raw pointer here.

Dariusz

Well I have this scenario

I run 50 threads
each of them Have 2000+ tcpclients
clients emit signal when they have specific data/etc
All their signals go to "manager" that then decided what to do with data using socketTread. So far I was passing sender pointer as a "helper-handler" but I'm slowly moving my app design from raw pointers to smart pointers. The TcpSockets don't have parent as they all live in different threads. I suppose their parent can be thread but still, it can be deleted before thread dies so... I'm just looking for a way to have "valid" pointer.

Christian Ehrlicher

@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'?

Dariusz

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

QPointer

Dariusz

@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

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

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

@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

@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

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

@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

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

@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.