Signals stops working

[JaroMast]

I have a question: is there a maximun number of signals that can occur at the same moment?
I found out the problem with QTcpSocket and QTimer (mostly).
ex. when i get some messages at the same time (about 10, 10 signals readyRead is emitted) after that i dont get any signals from socket.
Sometimes the same is happening with timer, it is working, in each second it emits timeout signal and sometimes it stops emiting (i checked the timer is still working but no timeout occurs)

[amleto]

yes, the maximum number of signals is 1 (per thread). That does not help you much because your question is poorly formed and does not address your actual problem. If you would like to divulge more information, perhaps you will get a more useful answer

[JaroMast]

Thx for your fast reply
So mayby from other side...
I have class Reader which is working on QTcpSocket, it just read message when readyRead occure;
After that, depends of message type, it emits other signal (emit mess, emit task etc)
From another class Writer i just write message using the same socket.
After sending some messages (lets say 10 x socket->write()) there are problems with Reader class (emit mess stops emiting when emit task works)
Is it possible that Qt somehow blocks 1 signal from object and allows another one?
(I also trying reconnecting signals/slots and blockSignals(true/false), nothing were able to reconnect "emit mess" signal)

[pkj]

I don't know what you mean by maximum number of signals at same moment. In one thread, executions are happening one statement at time. So obviously signal is also one at one point of time at one instant.
How slots are implemented after emitting signals depends on how slot was connected(Qt:irectConnection, QueuedConnection, etc).
Normally, if in the same thread, the slot is executed immediately, If slot is in other thread, it is posted as event on thread of slot. In due time, it is executed(queuedConnection).
Now with postedEvents like these, some get compressed, so 10 update() functions get compressed to just 1. However, not all, and certainly not your events are compressable.
Qt Signal and Slot mechanism works. In single threaded or multithreaded applications.
In multithreaded queued connections, underlying event system and qvariant system is used to queue the slot. paint events, move events, resize events, layout hint events, and language change events are compressible and can be missed if there are many at one loop of processevents. However, otherwise the events are not ignored even if the queue is flooded according to my knowledge.
My advice is not to doubt the signal slot mechanism and look for problems elsewhere.

[amleto]

Thx for your fast reply
So mayby from other side...
I have class Reader which is working on QTcpSocket, it just read message when readyRead occure;
After that, depends of message type, it emits other signal (emit mess, emit task etc)
From another class Writer i just write message using the same socket.
After sending some messages (lets say 10 x socket->write()) there are problems with Reader class (emit mess stops emiting when emit task works)
Is it possible that Qt somehow blocks 1 signal from object and allows another one?
(I also trying reconnecting signals/slots and blockSignals(true/false), nothing were able to reconnect "emit mess" signal)

99.999% probability, problem is your code, not Qt. Time to get your debugger out.