我参与构建了一个custum QGIS应用程序，其中实时数据将显示在应用程序的查看器上。
正在使用的IPC是unix消息队列。
数据将以指定的间隔刷新，例如3秒。
现在我遇到的问题是要显示的数据处理时间超过3秒，所以我所做的是在应用程序开始处理数据以进行下一次更新之前，刷新QTimer已停止，数据处理完毕后我再次重新启动QTimer。应用程序的工作方式应该是在更新/刷新后（在此刷新期间应用程序无响应），用户应该有足够的时间继续处理应用程序除了看到数据正在更新。我能够让用户可以接受暂停工作 - 在一种情况下。
但是在不同的操作系统（RHEL 5.0到RHEL 5.2）上，情况有所不同。计时器疯狂并继续点火而不会暂停任何暂停，因此进入无限循环。处理此更新数据肯定花费的时间超过3秒，但由于这个原因，我已经停止 - 在处理时重新启动计时器......并且在一个场景中同样的逻辑工作，而在其他情况下它不会..我观察到的另一个事实是当这个快速射击时计时器发生时刷新功能退出所需的时间非常小，超过300毫秒所以我在这个功能的开始和结束时放置的计时器的启动停止发生在那个小时间..所以数据的实际处理完成后，队列中的计时器有3-4次启动等待执行，因此每次连续更新时，无限循环问题从那一点变得更糟。
这里需要注意的重要一点是，对于一个操作系统中的相同代码，刷新时间显示为大约4000毫秒（相同数据量的实际处理时间），而另一个操作系统则为300毫秒。 / p>
也许这与更新的操作系统上的新库有关。但我不知道如何调试它，因为我无法得到任何线索为什么它发生这样...可能与pthreads相关的东西已经改变b / w操作系统??
所以，我的问题是，有什么方法可以确保我的应用程序中的某些处理是时间（并且独立于操作系统）而不使用QTimer，因为我认为QTimer不是一个很好的选择来实现我的目标想??
那里有什么选择？ pthreads还是Boost线程？如果我使用线程作为替代方案哪一个会更好？但是无论更新处理需要多长时间，我怎样才能确保至少3秒的间隙b / w连续更新？
请帮助。
感谢。
答案 0 :(得分：1)
如果我试图获得可接受的长期解决方案，我会调查在单独的线程中更新您的显示器。在该线程中，您可以将显示绘制到图像，根据需要随时更新...尽管您可能想要限制线程，因此不会占用所有处理时间。然后在UI线程中，您可以读取该图像并将其绘制到屏幕上。这可以提高您对平移的响应速度，因为您可以显示图像的不同部分。您可以根据计时器每3秒更新一次图像（只需从源重绘），或者每当新数据完全刷新时，您可以让另一个线程发出信号。