Difference between signal slots and events

Go from Network

In a closer look, there is little difference between events and signals, as long as we can register events or signal response functions in order to be notified when events or signals are generated. One difference, however, is that the return value of the event handler is meaningful, and we want to determine whether we want to continue the handling of the event based on the return value, such as in Qt, if the event handler returns TRUE, the event processing is complete, and qapplication will proceed to the next event. If False is returned, the event dispatch function continues to look up for the next registration method that can handle the event. The return value of the signal processing function is meaningless to the signal dispatcher.

Another issue that needs our attention is the prioritization of events and signal processing. In QT, events are all related to the window, so the event callback is started from the current window and is distributed upward at the first level until a window returns true, truncating the processing of the event.    The processing of the signal is relatively simple, the default is no order, if the need for a clear order, the signal can be registered to indicate the location of the slot. In Qt, the event uses an event queue to maintain, and if a new event is generated in the event's processing, the new event is added to the end of the queue until the current event is processed, and the qapplication goes to the queue header to take down an event to process. The signal processing method is somewhat different, signal processing is immediately callback, that is, after a signal is generated, all the slots he registered above will be immediately recalled. This results in a recursive call, such as a signal processor that generates a signal that will cause the signal to be processed like a tree.

Evaluation: Actually the signal-slot can also be asynchronous, this bool connect (const QOBJECT * sender, const char * signal, const QOBJECT * receiver, const char * meth OD, Qt::connectiontype type = qt::autocompatconnection)
The inside of the qt::autocompatconnection can be determined according to the actual situation

All classes that use signals and slots must contain Q_object macros, and this class must derive (directly or indirectly) from the Qobject class.
When a signal is emit out, the slot linked to this signal is immediately called, as if it were a function call. When this happens, the signal and slot mechanisms have absolutely nothing to do with the GUI's event loop, and after all the slots that link to this signal are executed, the code after the emit code line is executed immediately. When multiple slots are linked to a signal, these slots are executed in a random order, one after the other.
The Signal code is generated automatically by the MOC, and the developer must not implement it in its own C + + code, and it will never have a return value.
The slot is actually an ordinary class function, and can be called directly, the only special place is that it can be linked with signal.
The C + + preprocessor changes or removes the signal, slot, emit keyword, so, for the C + + compiler, it handles standard C + + source files.

The Signal/slot uses three ways to deliver messages at the bottom. BOOL Qobject::connect (const QOBJECT * sender, const char * signal, const QOBJECT * receiver, const char * method, Qt::co Nnectiontype type = qt::autocompatconnection)
The last parameter is the way the message is delivered, with four values:

1.Qt::D irectconnection
When emitted, the signal was immediately delivered to the slot.
Assuming that there are currently 4 slots connected to qpushbutton::clicked (BOOL), when the button is pressed, QT invokes the 4 slots in the concatenated chronological order. Obviously this way cannot cross threads (passing messages).

2.qt::queuedconnection
When emitted, the signal was queued until the event loop is able to deliver it to the slot.
Assuming that there are currently 4 slots connected to qpushbutton::clicked (BOOL), when the button is pressed, QT wraps the signal into a qevent and puts it in the message queue. Qapplication::exec () or qthread::exec () of the thread takes a message from the message queue and then calls several slots associated with signal. This way, you can either pass messages within the thread or pass messages across threads. 3.qt::blockingqueuedconnection
Same as queuedconnection, except that the current thread blocks until the slots has been delivered. This connection type should only is used for receivers in a different thread. Note that misuse of this type can leads to dead locks in your application.
Similar to qt::queuedconnection, but blocks until the associated slot is executed. Here is the word blocking, which means it is designed to deliver messages between multiple threads. 4.

Qt::autoconnection
If the signal is emitted from the thread in which the receiving object lives, the slot is invoked directly, as with Qt::D i Rectconnection; Otherwise the signal is queued and as with qt::queuedconnection.
This type of connection automatically selects QT based on whether the signal and slots are in the same thread::D irectconnection or Qt::queuedconnection

In this way, the first type of efficiency is certainly higher than the second, after all, the second way to store messages to the queue, and may involve the replication of large objects (consider sig_produced (BigObject bo), Bo needs to be copied into the queue).

QT Threads and Signal-slot ask Coredump or QT experts a question. QT thread, the main thread is the GUI, the secondary thread is a worker thread, if the secondary line thread also use message loop (exec), that is, the main/secondary communication with Signal-slot to achieve synchronization, in this case, 1. The main thread will be the sub-threading block? 2. If the single CPU will be block, if the secondary thread is constantly circulating, the lower layer will automatically allocate time slices to the main thread? 3. Does this approach and direct invocation of the methods in the thread, using mutexes and the like to achieve similar loops, the efficiency difference is big? Remember that QT says Signal-slot is just the difference between several function calls. Oh, ask not very clear, mainly is to ask, primary and secondary threads how to communicate more effectively. Thank you.

Qthread now has a message loop by default, and encourages the use of thread-independent message loops 1. Will the main thread be blocked by the sub-threads? No, QOBJECT::CONNECTD. The last parameter uses Qt::autoconnection by default, in a multithreaded environment, the Qt::queuedconnection mode is automatically selected, unless QT is enforced: Blockingqueuedconnection or Qt::D irectconnection, otherwise the thread will not block. 2. If the single CPU will be block, if the secondary thread is constantly circulating, the lower layer will automatically allocate time slices to the main thread? The number of threads and CPUs is not related, of course, the CPU is more, running will be more process, the resource allocation of the thread (time slice) is managed by the operating system, on each system is so 3. This method and the method directly called the thread, using the mutex and other to achieve similar loops, efficiency difference? Execution efficiency is difficult to say, but the mutex is certainly the result of the reduction of development efficiency, you have to carefully handle the various critical resource lock problem 4. Remember Qt said Signal-slot just a few more function call differences Yes, signal-slot this slight loss of efficiency is not a problem in most cases, unless overused, this is generally a design error resulting from sharing two articles, Speaking of Qthread and QT Signal-slot: 1 is a QT Labs blog on a doing it wrong ... (http://labs.trolltech.com/blogs/2010/06/17/youre-doing-it-wrong/), this article is very interesting, in fact, many people do not know that the original qthread can also be used. Another article is about how to use Qt's signal-slot mechanism and qthread for complete lock free programming (http://thesmithfam.org/blog/2009 ... ti-threading-in-qt/)

Reply, and then learn to go. The reason why I asked, because I did a download GoogleMap program, after the beginning of the download thread, the GUI will not move until the end of the download. Although the operating system allocates time, does it still have an impact if the download thread loops and has the same priority?

I'll see where the problem is. Just looked at you above two links, really to the point of Ah, hehe, has been pondering this period of time. Summarize the understanding and see if it is right. In the first article, the default run () in Qthread has started the message loop exec (). When a new thread is needed, the Qthread, start () should be generated directly. As for the function, it should be placed in another class, set the Signal-slot before calling start, and then movetothread to Qthread. No Sunbclass qthread. I have been or re-implemented run (), generating all objects in run (), Signal-slot, or Qthread.movetothread (Qthread) as described in this article. Both of these have many problems and undermine the concept of oo. Very clear.

In the second part of the Signal-slot to synchronize with the thread, just answer the previous questions, but he used Qthread method is exactly contrary to the first article of thought.

Reference:

originally Posted by GPS on 12-7-2010 12:40 I'll see what's wrong. Just looked at you above two links, really to the point of Ah, hehe, has been pondering this period of time. Summarize the understanding and see if it is right. In the first article, the default run () in Qthread has started the message loop exec (). When new threads are needed

...

Another way is also good, in some cases must subclass qthread, wrong is not whether subclass, wrong in: subclassing Qthread, adding signal and slot code to that subclass, and Then calling Movetothread (this); Reference:

The

to set the record straight:i ' m isn't saying sub-classing Qthread is wrong. This is also how Java does it (sort of), and many people has been doing this with Qt for a long time. what I ' m sayin G is "wrong" is subclassing qthread, adding signal and slots code to that subclass, and then calling Movetothread (this); In the constructor of that subclass. This causes people lots of confusion from my experience and observation on the #qt channel and the Qt-interest mailing lis T. And yes, the current docs is still a bit lacking, something that I am fully aware of (and take responsibility for ). I ' m planning on sitting down and fleshing them out, showing both ways of the using qthread (with and without subclassing).

In the QT programming model, thread and signal-slot are all means of implementing asynchronous programming, and Signal-slot is behind the message loop, and each thread is a separate message loop, and in earlier versions, the QT thread was unable to Signal-slot messaging, which causes each message loop to be independent of the loop, only the global state+ mutex lock is the only way to communicate. After 4.x, Signal-slot has been able to get along with thread. In this way, the ideal QT programming model becomes a separate task, each using their own thread and thread internal message loop, when it is necessary to communicate with each other, using signal-slot, these signal and slots are clearly defined message interface, in addition, It is best not to share other states. The QT programmer is a bit like an acrobat who turns dishes, each of which rotates on its own, and the whole system consists of a lot of rotating plates that can share the Acrobat one hand, or the other hand or even a different Acrobat to control (multi-CPU)

Difference between signal slots and events