信号槽 與事件差別

信号槽 與事件差別

仔細來看，事件與信号其實并無多大差别，從我們對其需求上來說，都隻要能注冊事件或信号響應函數，在事件或信号産生時能夠被通知到即可。但有一項差別在于，事件處理函數的傳回值是有意義的，我們要根據這個傳回值來确定是否還要繼續事件的處理，比如在QT中，事件處理函數如果傳回true，則這個事件處理 已完成，QApplication會接着處理下一個事件，而如果傳回false，那麼事件分派函數會繼續向上尋找下一個可以處理該事件的注冊方法。信号處 理函數的傳回值對信号分派器來說是無意義的。

    另外還有一個需要我們關注的問題是事件和信号處理時的優先級問題。在QT中，事件因為都是與視窗相關的，是以事件回調時都是從目前視窗開始，一級一級向上 派發，直到有一個視窗傳回true，截斷了事件的處理為止。對于信号的處理則比較簡單，預設是沒有順序的，如果需要明确的順序，可以在信号注冊時顯示地指 明槽的位置。

    在QT中，事件使用了一個事件隊列來維護，如果事件的進行中又産生了新的事件，那麼新的事件會加入到隊列尾，直到目前事件處理完畢後， QApplication再去隊列頭取下一個事件來處理。而信号的處理方式有些不同，信号處理是立即回調的，也就是一個信号産生後，他上面所注冊的所有槽 都會立即被回調。這樣就會産生一個遞歸調用的問題，比如某個信号處理器中又産生了一個信号，會使得信号的處理像一棵樹一樣的展開。

評價：實際上信号-槽也可以異步的，這個bool connect ( const QObject * sender, const char * signal, const QObject * receiver, const char * method, Qt::ConnectionType type = Qt::AutoCompatConnection )

裡面的Qt::AutoCompatConnection，可以根據實際情況确定

 所有使用了信号和槽的類都必須包含 Q_OBJECT 宏，而且這個類必須從QObject類派生(直接或者間接派生)出來，

    當一個signal被emit出來的時候，連結到這個signal的slot會立刻被調用，就好像是一個函數調用一樣。當這件事情發生的時 候，signal和slot機制與GUI的事件循環完全沒有關系，當所有連結到這個signal的slot執行完成之後，在 emit 代碼行之後的代碼會立刻被執行。當有多個slot連結到一個signal的時候，這些slot會一個接着一個的、以随機的順序被執行。

    Signal 代碼會由 moc 自動生成，開發人員一定不能在自己的C++代碼中實作它，并且，它永遠都不能有傳回值。

    Slot其實就是一個普通的類函數，并且可以被直接調用，唯一特殊的地方是它可以與signal相連結。

    C++的預處理器更改或者删除 signal, slot, emit 關鍵字，是以，對于C++編譯器來說，它處理的是标準的C++源檔案。

    signal/slot 在底層會使用三種方式傳遞消息。bool QObject::connect ( const QObject * sender, const char * signal, const QObject * receiver, const char * method, Qt::ConnectionType type = Qt::AutoCompatConnection )

最後一個參數是就是傳遞消息的方式了，有四個取值：

1.Qt::DirectConnection

When emitted, the signal is immediately delivered to the slot.

假設目前有4個slot連接配接到QPushButton::clicked(bool)，當按鈕被按下時，QT就把這4個slot按連接配接的時間順序調用一遍。顯然這種方式不能跨線程（傳遞消息）。

2.Qt::QueuedConnection

When emitted, the signal is queued until the event loop is able to deliver it to the slot.

假 設目前有4個slot連接配接到QPushButton::clicked(bool)，當按鈕被按下時，QT就把這個signal包裝成一個 QEvent，放到消息隊列裡。QApplication::exec()或者線程的QThread::exec()會從消息隊列裡取消息，然後調用 signal關聯的幾個slot。這種方式既可以線上程内傳遞消息，也可以跨線程傳遞消息。

3.Qt::BlockingQueuedConnection

Same as QueuedConnection, except that the current thread blocks until the slot has been delivered. This connection type should only be used for receivers in a different thread. Note that misuse of this type can lead to dead locks in your application.

與Qt::QueuedConnection類似，但是會阻塞等到關聯的slot都被執行。這裡出現了阻塞這個詞，說明它是專門用來多線程間傳遞消息的。

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::DirectConnection; otherwise the signal is queued, as with Qt::QueuedConnection.

這種連接配接類型根據signal和slot是否在同一個線程裡自動選擇Qt::DirectConnection或Qt::QueuedConnection

Qt的線程和 signal-slot

再問coredump或者QT高手們一個問題。QT裡用線程，主線程是GUI，次線程是工作線程，如果次線程裡也用消息循環(exec)，即，主/次間用signal-slot通訊來實作同步，在這種情況下， 1.主線程會被次線程block嗎？ 2.如果在單cpu裡會被block嗎，如果次線程裡不斷循環，低層會自動配置設定時間片給主線程嗎？ 3.這種方法和直接調用次線程中的方法，用mutex之類的來實作類似的循環，效率差别大嗎？記得QT裡講過signal-slot隻是多幾個函數調用的差别。 呵呵，問的不太清楚，主要就是想問一下，主次線程中怎樣通訊比較有效。 謝謝阿。

QThread 現在預設狀态下就是有一個消息循環的，而且鼓勵使用線程獨立的消息循環 1.主線程會被次線程block嗎？ 不會，QObject::connectd的最後一個參數預設使用Qt::AutoConnection, 在多線程環境下，會自動選擇Qt::QueuedConnection方式，除非強制使用Qt::BlockingQueuedConnection或者 Qt::DirectConnection， 否則線程不會block. 2.如果在單cpu裡會被block嗎，如果次線程裡不斷循環，低層會自動配置設定時間片給主線程嗎？ 線程和CPU個數沒有關系，當然CPU多了，運作會更加流程，線程的資源配置設定(時間片)是由作業系統管理的，在各個系統上都是如此 3.這種方法和直接調用次線程中的方法，用mutex之類的來實作類似的循環，效率差别大嗎? 執行效率上很難講，但是mutex肯定是帶來了開發效率的降低，你得小心翼翼地處理好各種臨界資源的鎖問題 4. 記得QT裡講過signal-slot隻是多幾個函數調用的差别 是的，signal-slot的這種輕微的效率損失在絕大多數情況下不是問題，除非過度使用，這一般是設計上的錯誤導緻的 分享兩篇文章，講QThread和Qt的signal-slot的: 1篇是qt labs的部落格上一篇 You are doing it wrong...(http://labs.trolltech.com/blogs/2010/06/17/youre-doing-it-wrong/), 這篇文章很有意思，其實很多人不知道原來QThread還可以這樣用。 另外一篇是關于怎麼利用Qt的signal-slot機制和QThread進行完全的lock free程式設計(http://thesmithfam.org/blog/2009 ... ti-threading-in-qt/)

多謝多謝，再學習去。 之是以問，是因為，我做了一個下載下傳googlemap的程式，開始下載下傳線程後，GUI就不動了，直到下載下傳結束。雖然作業系統會配置設定時間，但是如果下載下傳線程循環，而且優先級相同的話，是不是還是有影響？

我再看看哪裡出問題了。 剛看了你上面的兩個連結，真是切中要害阿，呵呵，一直就在琢磨這個一段時間了。 總結一下了解，看看對不對。 第一篇裡，QThread裡預設的run()已經啟動了消息循環exec(). 當需要新線程時，應該，直接生成QThread, start()。至于功能，應該放在另外的類裡，在調用start前設定好signal-slot，再moveToThread到 QThread中。 不用sunbclass QThread。 我一直或者重新實作run（），在run()裡生成所有object, signal-slot, 或者如文中所說的QThread.moveToThread(QThread). 這兩種都有不少問題，破壞OO的概念。 很清楚。

第二篇裡講了用線程間的signal-slot來同步，正好回答了之前的疑問，不過他使用qthread的方法恰恰違背了第一篇的思想。

引用:

原帖由 GPS 于 12-7-2010 12:40 發表  我再看看哪裡出問題了。 剛看了你上面的兩個連結，真是切中要害阿，呵呵，一直就在琢磨這個一段時間了。 總結一下了解，看看對不對。 第一篇裡，QThread裡預設的run()已經啟動了消息循環exec(). 當需要新線程時 ...

另一種方式也不錯，有些情況下必須subclass QThread, 錯的不是是否subclass，錯在：subclassing QThread, adding signal and slot code to that subclass, and then calling moveToThread(this);

To set the record straight: I’m not saying sub-classing QThread is wrong. This is also how Java does it (sort of), and many people have been doing this with Qt for a long time. What I’m saying is “wrong” is subclassing QThread, adding signal and slot 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 list. And yes, the current docs are 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 using QThread (with and without subclassing).

在Qt的程式設計模型裡，thread和signal- slot都是實作異步程式設計的手段，signal-slot的背後是消息循環，而每個thread都是一個獨立的消息循環，在早期版本，qt線程間無法進行 signal-slot消息傳遞，這就導緻了各個消息循環都是互相獨立的loop, 通訊的唯一方式隻剩下global state+ mutex lock。在4.x 之後，signal-slot已經能夠和thread融洽相處了。 這樣，理想的QT程式設計模型就變成了獨立的一個個任務，各自 使用自己的thread和thread内部消息循環，在需要互相通訊的時候，使用signal-slot, 這些signal和slot就是明确定義的消息接口，除此之外，最好不共享其它狀态。Qt程式員有點像轉盤子的雜技演員，每個盤子都獨自轉動，整個系統由 很多旋轉的盤子組成，這些盤子可以共享雜技演員一個手，也可以是另一隻手甚至不同的雜技演員來控制(多CPU)