事件循环与线程 一

初次读到这篇文章，译者感觉如沐春风，深刻体会到原文作者是花了很大功夫来写这篇文章的，文章深入浅出，相信仔细读完原文或下面译文的读者一定会有收获。

由于原文很长，原文作者的行文思路是从事件循环逐渐延伸到线程使用的讨论，译者因时间受限，暂发表有关事件循环的译文。另一半线程实用的译文将近期公布。文中有翻译不当的地方，还请见谅。

介绍

线程是qt channel里最流行的讨论话题之一。许多人加入了讨论并询问如何解决他们在运行跨线程编程时所遇到的问题。

快速检阅一下他们的代码，在发现的问题当中，十之八九遇到得最大问题是他们在某个地方使用了线程，而随后又坠入了并行编程的陷阱。Qt中创建、运行线程的“易用”性、缺乏相关编程尤其是异步网络编程知识或是养成的使用其它工具集的习惯、这些因素和Qt的信号槽架构混合在一起，便经常使得人们自己把自己射倒在了脚下。此外，Qt对线程的支持是把双刃剑：它即使得你在进行Qt多线程编程时感觉十分简单，但同时你又必须对Qt所新添加许多的特性尤为小心，特别是与QObject的交互。

本文的目的不是教你如何使用线程、如何适当地加锁，也不是教你如何进行并行开发或是如何写可扩展的程序；关于这些话题，有很多好书，比如这个链接给的推荐读物清单.  这篇文章主要是为了向读者介绍Qt 4的事件循环以及线程使用，其目的在于帮助读者们开发出拥有更好结构的、更加健壮的多线程代码，并回避Qt事件循环以及线程使用的常见错误。

先决条件

考虑到本文并不是一个线程编程的泛泛介绍，我们希望你有如下相关知识：

  • C++基础；
  • Qt 基础：QOjbects , 信号/槽，事件处理；
  • 了解什么是线程、线程与进程间的关系和操作系统；
  • 了解主流操作系统如何启动、停止、等待并结束一个线程；
  • 了解如何使用mutexes, semaphores 和以及wait conditions 来创建一个线程安全/可重入的函数、数据结构、类。

本文我们将沿用如下的名词解释，即

  • 可重入 一个类被称为是可重入的：只要在同一时刻至多只有一个线程访问同一个实例，那么我们说多个线程可以安全地使用各自线程内自己的实例。 一个函数被称为是可重入的：如果每一次函数的调用只访问其独有的数据（译者注：全局变量就不是独有的，而是共享的），那么我们说多个线程可以安全地调用这个函数。 也就是说，类和函数的使用者必须通过一些外部的加锁机制来实现访问对象实例或共享数据的序列化。
  • 线程安全  如果多个线程可以同时使用一个类的对象，那么这个类被称为是线程安全的；如果多个线程可以同时使用一个函数体里的共享数据，那么这个函数被称为线程安全的。

(译者注：   更多可重入(reentrant)和t线程安全(thread-safe)的解释：  对于类，如果它的所有成员函数都可以被不同线程同时调用而不相互影响——即使这些调用是针对同一个类对象，那么该类被定义为线程安全。 对于类，如果其不同实例可以在不同线程中被同时使用而不相互影响，那么该类被定义为可重入。在Qt的定义中，在类这个层次，thread-safe是比reentrant更严格的要求)

事件与事件循环

Qt作为一个事件驱动的工具集，其事件和事件派发起到了核心的作用。本文将不会全面的讨论这个话题，而是会聚焦于与线程相关的一些关键概念。想要了解更多的Qt事件系统专题参见 (这里[doc.qt.nokia.com] 和 这里[doc.qt.nokia.com] ) （译者注：也欢迎参阅译者写的博文：浅议Qt的事件处理机制一，二）

一个Qt的事件是代表了某件另人感兴趣并已经发生的对象；事件与信号的主要区别在于，事件是针对于与我们应用中一个具体目标对象（而这个对象决定了我们如何处理这个事件），而信号发射则是“漫无目的”。从代码的角度来说，所有的事件实例是QEvent [doc.qt.nokia.com]的子类，并且所有的QObject的派生类可以重载虚函数QObject::event(),从而实现对目标对象实例事件的处理。

事件可以产生于应用程序的内部，也可以来源于外部；比如：

  • QKeyEvent和QMouseEvent对象代表了与键盘、鼠标相关的交互事件，它们来自于视窗管理程序。
  • 当计时器开始计时，QTimerEvent 对象被发送到QObject对象中，它们往往来自于操作系统。
  • 当一个子类对象被添加或删除时，QChildEvent对象会被发送到一个QObject对象重，而它们来自于你的应用程序内部

对于事件来讲，一个重要的事情在于它们并没有在事件产生时被立即派发，而是列入到一个事件队列（Event queue）中，等待以后的某一个时刻发送。分配器（dispatcher ）会遍历事件队列，并且将入栈的事件发送到它们的目标对象当中，因此它们被称为事件循环（Event loop）. 从概念上讲,下段代码描述了一个事件循环的轮廓:

[cpp] view plaincopy
  1. 1:  while (is_active)  
  2. 2:  {  
  3. 3:      while (!event_queue_is_empty)  
  4. 4:          dispatch_next_event();  
  5. 5:     
  6. 6:      wait_for_more_events();  
  7. 7:  }  

我们是通过运行QCoreApplication::exec()来进入Qt的主体事件循环的；这会引发阻塞，直至QCoreApplication::exit() 或者 QCoreApplication::quit() 被调用，进而结束循环。

这个“wait_for_more_events()” 函数产生阻塞，直至某个事件的产生。 如果我们仔细想想，会发现所有在那个时间点产生事件的实体必定是来自于外部的资源（因为当前所有内部事件派发已经结束，事件队列里也没有悬而未决的事件等待处理），因此事件循环被这样唤醒：

  • 视窗管理活动（键盘按键、鼠标点击，与视窗的交互等等）；
  • socket活动 （有可见的用来读取的数据或者一个可写的非阻塞Socket, 一个新的Socket连接的产生）；
  • timers (即计时器开始计时）
  • 其它线程Post的事件（见后文）。

Unix系统中，视窗管理活动（即X11）通过Socket（Unix 域或者TCP/IP）通知应用程序（事件的产生），因为客户端使用它们与X服务器进行通讯。 如果我们决定用一个内部的socketpair(2)来实现跨线程的事件派发，那么视窗管理活动需要唤醒的是

  • sockets;
  • timers;

这也是select(2) 系统调用所做的： 它为视窗管理活动监控了一组描述符，如果一段时间内没有任何活动，它会超时。Qt所要做的是把系统调用select的返回值转换为正确的QEvent子类对象，并将其列入事件队列的栈中，现在你知道事件循环里面装着什么东西了吧:)

为什么需要运行事件循环？

下面的清单并不全，但你会有一幅全景图，你应该能够猜到哪些类需要使用事件循环。

  • Widgets 绘图与交互： 当派发QPaintEvent事件时，QWidget::paintEvent() 将会被调用。QPaintEvent可以产生于内部的QWidget::update() ，也可以产生于外部的视窗管理（比如，一个显示被隐藏的窗口）。同样的，各种各样的交互（键盘、鼠标等）所对应的事件均需要事件循环来派发。
  • Timers: 长话短说，当select(2)或相类似的调用超时时，计时器开始计时，因此需要让Qt通过返回事件循环让那些调用为你工作。
  • Networking: 所以底层的Qt网络类(QTcpSocket, QUdpSocket, QTcpServer等)均被设计成异步的。当你调用read()时，它们仅仅是返回已经可见的数据而已； 当你调用write()时，它们仅是将写操作列入执行计划表待稍后执行。 真正的读写仅发生于事件循环返回的时候。 请注意虽然Qt网络类提供了相应的同步方法（waitFor* 一族），但它们是不被推荐使用的，原因在于他们阻塞了正在等待的事件循环。向QNetworkAccessManager这样的上层类，并不提供同步API 而且需要事件循环。

阻塞事件循环

在讨论为什么你永远都不要阻塞事件循环之前，让我们尝试着再进一步弄明白到底“阻塞”意味着什么。假定你有一个按钮widget，它被按下时会emit一个信号；还有一个我们下面定义的Worker对象连接了这个信号，而且这个对象的槽做了很多耗时的事情。当你点击完这个按钮后，从上之下的函数调用栈如下所示：

[cpp] view plaincopy
  1. main(int, char **)  
  2. QApplication::exec()  
  3. [...]  
  4. QWidget::event(QEvent *)  
  5. Button::mousePressEvent(QMouseEvent *)  
  6. Button::clicked()  
  7. [...]  
  8. Worker::doWork()  

在main()中，我们通过调用QApplication::exec() （如上段代码第2行所示）开启了事件循环。视窗管理者发送了鼠标点击事件，该事件被Qt内核捕获，并转换成QMouseEvent ，随后通过QApplication::notify() （notify并没有在上述代码里显示）发送到我们的widget的event()方法中（第4行）。因为Button并没有重载event()，它的基类QWidget方法得以调用。 QWidget::event() 检测出传入的事件是一个鼠标点击，并调用其专有的事件处理器，即Button::mousePressEvent() (第5行)。我们重载了 mousePressEvent方法，并发射了Button::clicked()信号（第6行），该信号激活了我们worker对象中十分耗时的Worker::doWork()槽（第8行）。（译者注：如果你对这一段所描述得函数栈的更多细节，请参见浅议Qt的事件处理机制一，二）

当worker对象在繁忙的工作时，事件循环在做什么呢？ 你也许猜到了答案：什么也没做！它分发了鼠标点击事件，并且因等待event handler返回而被阻塞。我们阻塞了事件循环，也就是说，在我们的doWork()槽（第8行）干完活之前再不会有事件被派发了，也再不会有pending的事件被处理。

当事件派发被就此卡住时，widgets 也将不会再刷新自己（QPaintEvent对象将在事件队列里静候），也不能有进一步地与widgets交互的事件发生，计时器也不会在开始计时，网络通讯也将变得迟钝、停滞。更严重的是，许多视窗管理程序会检测到你的应用不再处理事件，从而告诉用户你的程序不再有响应（not responding）. 这就是为什么快速的响应事件并尽可能快的返回事件循环如此重要的原因

强制事件循环

那么，对于需要长时间运行的任务，我们应该怎么做才会不阻塞事件循环？ 一个可行的答案是将这个任务移动另一个线程中：在一节，我们会看到如果去做。一个可能的方案是，在我们的受阻塞的任务中，通过调用QCoreApplication::processEvents() 人工地强迫事件循环运行。QCoreApplication::processEvents() 将处理所有事件队列中的事件并返回给调用者。

另一个可选的强制地重入事件的方案是使用QEventLoop [doc.qt.nokia.com] 类，通过调用QEventLoop::exec() ，我们重入了事件循环，而且我们可以把信号连接到QEventLoop::quit() 槽上使得事件循环退出，如下代码所示：

[cpp] view plaincopy
  1. 1:  QNetworkAccessManager qnam;  
  2. 2:  QNetworkReply *reply = qnam.get(QNetworkRequest(QUrl(...)));  
  3. 3:  QEventLoop loop;  
  4. 4:  QObject::connect(reply, SIGNAL(finished()), &loop, SLOT(quit()));  
  5. 5:  loop.exec();  
  6. 6:  /* reply has finished, use it */  

QNetworkReply 没有提供一个阻塞式的API，而且它要求运行一个事件循环。我们进入到一个局部QEventLoop，并且当回应完成时，局部的事件循环退出。

当重入事件循环是从“其他路径”完成的则要非常小心：它可能会导致无尽的递归循环！让我们回到Button这个例子。如果我们再在doWork() 槽里面调用QCoreApplication::processEvents() ，这时用户又一次点击了button，那么doWork()槽将会再次被调用：

[cpp] view plaincopy
  1. main(int, char **)  
  2. QApplication::exec()  
  3. [...]  
  4. QWidget::event(QEvent *)  
  5. Button::mousePressEvent(QMouseEvent *)  
  6. Button::clicked()  
  7. [...]  
  8. Worker::doWork() // 实现，内部调用  
  9. QCoreApplication::processEvents() // 我们人工的派发事件而且…  
  10. [...]  
  11. QWidget::event(QEvent *) // 另一个鼠标点击事件被发送给Button  
  12. Button::mousePressEvent(QMouseEvent *)  
  13. Button::clicked() // 这里又一次emit了clicked() …  
  14. [...]  
  15. Worker::doWork() // 完蛋! 我们已经递归地调用了doWork槽  

一个快速并且简单的临时解决办法是把QEventLoop::ExcludeUserInputEvents 传递给QCoreApplication::processEvents(), 也就是说，告诉事件循环不要派发任何用户输入事件（事件将简单的呆在队列中）。

同样地，使用一个对象的deleteLater() 来实现异步的删除事件（或者，可能引发某种“关闭（shutdown）”的任何事件）则要警惕事件循环的影响。 （译者注：deleteLater()将在事件循环中删除对象并返回）

[cpp] view plaincopy
  1. 1:  QObject *object = new QObject;  
  2. 2:  object->deleteLater();  
  3. 3:  QEventLoop loop;  
  4. 4:  loop.exec();  
  5. 5:  /* 现在object是一个野指针! */  
 

可以看到，我们并没有用QCoreApplication::processEvents()  (从Qt 4.3之后，删除事件不再被派发 ），但是我们确实用到了其他的局部事件循环（像我们QEventLoop 启动的这个循环，或者下面将要介绍的QDialog::exec()）。

切记当我们调用QDialog::exec()或者 QMenu::exec()时，Qt进入了一个局部事件循环。Qt 4.5 以后的版本，QDialog 提供了QDialog::open() 方法用来再不进入局部循环的前提下显示window-modal式的对话框

[cpp] view plaincopy
  1. 1:  QObject *object = new QObject;  
  2. 2:  object->deleteLater();  
  3. 3:  QDialog dialog;  
  4. 4:  dialog.exec();  
  5. 5:  /* 现在object是一个野指针! */  

至此事件循环（event loop）的讨论告一段落，接下来，我们要讨论Qt的多线程：事件循环与线程二

 原文：http://blog.csdn.net/changsheng230/article/details/6101232

请尊重原创作品和译文。转载请保持文章完整性，并以超链接形式注明原始作者主站点地址，方便其他朋友提问和指正。 

【推广】 免费学中医，健康全家人
原文地址：https://www.cnblogs.com/cy568searchx/p/3625866.html