今天是個好日子，嗯。
信號槽機制是Qt的特色功能之一，類似於windows中的消息機制，在不同的類對象間傳遞消息時我們經常使用信號槽機制，然而很多時候都沒有去關注connect()函數到底有幾種重載的形式，其中的各項參數都是什么。
如果總是浮於表面，僅僅是滿足於功能實現，而不去深究有哪些可能影響程序行為的參數，或者是作為一種GUI開發框架，她實現這種機制的原理是什么的話，一則是可能得不到提高，二則是在面試的時候問及這些問題時往往只能給出一個模糊的答案。
因此，在接下來的幾篇文章中，從最常用的connect參數選擇上開始，對Qt的信號槽機制及其實現原理做一次比較深入的梳理。
我們最常用的connect()函數的原型之一如下：
QMetaObject::Connection QObject::connect(const QObject * sender, const char * signal, const QObject * receiver, const char * method, Qt::ConnectionType type = Qt::AutoConnection)
最后的ConnectionType是一個缺省的參數，默認為自動連接方式，我們來看一下這個參數有哪些值：
1. AutoConnection
自動連接，默認值。
If the signal is emitted in the thread which the receiving object has affinity then the behavior is the same as the Direct Connection.
Otherwise, the behavior is the same as the Queued Connection.
如果信號的發送者和信號的接受者的對象同屬一個線程，那個工作方式與直連方式相同；否則工作方式與排隊方式相同。
2. Direct Connection
直接連接。
The slot is invoked immediately, when the signal is emitted. The slot is executed in the emitter's thread, which is not necessarily the receiver's thread.
當信號發出后，相應的槽函數將立即被調用；
emit語句后的代碼將在所有槽函數執行完畢后被執行，信號與槽函數關系類似於函數調用，同步執行。
3. Queued Connection
排隊方式連接。
The slot is invoked when control returns to the event loop of the receiver's thread. The slot is executed in the receiver's thread.
當信號發出后，排隊到信號隊列中，需等到接收對象所屬線程的事件循環取得控制權時才取得該信號，調用相應的槽函數。
emit語句后的代碼將在發出信號后立即被執行，無需等待槽函數執行完畢；
此時信號被塞到信號隊列里了，信號與槽函數關系類似於消息通信，異步執行。
4. Blocking Queued Connection
阻塞的排隊方式。
The slot is invoked as for the Queued Connection, except the current thread blocks until the slot returns.
Using this type to connect objects in the same thread will cause deadlock.
5. Unique Connection
The behavior is the same as the Auto Connection, but the connection is made only if it does not duplicate an existing connection.
Be aware that using direct connections when the sender and receiver live in different threads is unsafe if an event loop is running in the receiver's thread, for the same reason that calling any function on an object living in another thread is unsafe.
即跨線程調用QObject是線程不安全的。
但這個怎么理解呢？