QSocketNotifier: socket notifiers cannot be disabled from another thread

[jacek]

Qt::AutoConnection (slot is executed in main thread):

That's quite interesting. The docs say:

If the signal is emitted from the thread in which the receiving object lives, the slot is invoked directly, as with Qt::DirectConnection; otherwise the signal is queued, as with Qt::QueuedConnection.

So it looks like that if you use Qt::AutoConnection, the effective connection type is established for each signal, not once when the connection is created.

Qt::QueuedConnection (slot is executed in main thread):

It looks like the Client object lives in the main thread, so the meta call events go through main thread's event queue. One possible solution is to use QObject::moveToThread() (of course in such case there must be an event loop running in the Client thread).

[dabiabilus]

That's quite interesting. The docs say:
So it looks like that if you use Qt::AutoConnection, the effective connection type is established for each signal, not once when the connection is created.


It looks like the Client object lives in the main thread, so the meta call events go through main thread's event queue. One possible solution is to use QObject::moveToThread() (of course in such case there must be an event loop running in the Client thread).

I solve the problem as below, but there is other things to solve.

Sender thread lives in main thread.
Client lives main thread.
Socket lives in Client thread.

As you have said , with direct connection between sender and client ,Client slot is invoked in sender thread. That is why, slot can not write to socket due to fact that socket lives in Client thread.

With queued connection between sender and client , slot of Client is invoked in main thread because client lives in main thread. That is why, client slot can not write socket due to fact that socket lives in Client thread not in main thread.

To solve the problem, I have created new class that is responsible for initialization of the socket. This class also have slot that writes to the socket. I have created this class in the run block of the Client class. And connect to signal of the sender with slot of this class. it worked correctly using queud connection but as you said I needed "exec" call to be able use queued connection.

But when I call "exec" it blocks in the run block. I can not do anything inside. for example I can not use blocking approach as follows.

while (!quit) 
       {
 
         if (tcpSocket->waitForReadyRead(Timeout)) 
		 {
			// Read data
			QDataStream in(tcpSocket);
			in.setVersion(QDataStream::Qt_4_0);
			in >> buffer;
			qDebug() << buffer<<endl;
 
         }
      }

while (!quit) 
       {
		 
         if (tcpSocket->waitForReadyRead(Timeout)) 
		 {
			// Read data
			QDataStream in(tcpSocket);
			in.setVersion(QDataStream::Qt_4_0);
			in >> buffer;
			qDebug() << buffer<<endl;
			
         }
      }

To copy to clipboard, switch view to plain text mode 

because I have to read and write same socket in my design I have to alternative

1 -) Do not use blocking approach. Use simply signal / slot way. but as I know signals are slow . my application time critical. should handle lots of messages.I can not choose this approach.

2-) use blocking approach but create separe sockets for writing and reading.

3-) Use an other socket library

am I right ?

[danadam]

As you have said , with direct connection between sender and client ,Client slot is invoked in sender thread. That is why, slot can not write to socket due to fact that socket lives in Client thread.

With queued connection between sender and client , slot of Client is invoked in main thread because client lives in main thread. That is why, client slot can not write socket due to fact that socket lives in Client thread not in main thread.

To say the truth I don't know why you can't write to socket in different thread. My previous guessing was only... er... guessing. I checked that and it appears that there is no problem with writing to socket in sender thread or main thread. Client slot in the above examples did it and it wasn't complaining.

[jacek]

1 -) Do not use blocking approach. Use simply signal / slot way. but as I know signals are slow

What exactly is slow in signals?

am I right ?

There is also a 4th solution: you can use a non-blocking approach without using signals and slots.