1


0

ライブデータをアプリケーションのビューアに表示するためのカスタムQGISアプリケーションの構築に携わってきました。

使用されているIPCは、unixメッセージキューです。

データは指定された間隔、たとえば3秒で更新されます。

今直面している問題は、表示されるデータの処理に3秒以上かかることです。そのため、アプリが次の更新のためにデータの処理を開始する前に、refresh QTimerが停止することがあります。そして、データが処理された後、私は再びQTimerを再起動します。アプリは更新/更新の後(この更新の間にアプリが応答しなくなる)ユーザーは別としてアプリで作業を続けるための十分な時間を得るべきです。データが更新されているのを確認します。1つのシナリオでは、ユーザーが作業するための許容できる一時停止を取得できます。

しかし、異なるOS(RHEL 5.0からRHEL 5.2まで)では状況が少し違ってきます。タイマーは暴走し続け、連続した更新を一時停止することなく起動し続け、無限ループに陥ります。 3秒、しかしそのために私は処理中にタイマーを停止して再起動しました。 私が観察した他の事実は、タイマーのこの速い発火が起こるとき、リフレッシュ機能が終了するのにかかる時間が非常に小さいabt 300msであるので、私が始めと終わりに置いたタイマーの開始 - 停止データの実際の処理が終了する前に、キュー内で実行されるのを待っている3〜4のタイマーの開始があるので、無限ループ問題は連続更新ごとに悪化します。 。

ここで注意すべき重要なことは、あるOSの同じコードの場合、更新時間は約4000ms(同じ量のデータにかかる実際の処理時間)であることが示されていますが、他のOSの場合は300msです。

たぶん、これはアップデートされたOS上の新しいlibsと関係があるのでしょう。しかし私はそれがどうしてそのように起こっているのか手がかりを得ることができないのでそれをデバッグする方法を知りません…​ たぶんpthreadsに関連した何かがOSによって白黒を変えました?

それで、私の質問は、QTimerは私が欲しいものを達成するための良いオプションではないと思うのでQTimerを使用せずに私のアプリのいくつかの処理がtimerisedであることを保証する方法です

どんな選択肢がありますか? pthreadsまたはBoost thread? 私は代替としてスレッドを使用するのであればどれが良いでしょうか?

親切に助けてください。

ありがとう。

1 Answer


1


私が許容できる、より長期的な解決策を得ようとしていたならば、私はあなたのディスプレイを別のスレッドで更新することを調査するでしょう。 そのスレッドでは、あなたが望むように頻繁に更新しながら、画像にディスプレイをペイントすることができます…​ ただし、利用可能な処理時間のすべてがかからないようにスレッドを調整することをお勧めします。 それからUIスレッドで、あなたはそのイメージを読んでスクリーンにそれを描くことができます。 画像のさまざまな部分が表示される可能性があるため、パン操作に対する反応がよくなります。 あなたは(ソースからただ再描画する)タイマーに基づいて3秒毎に画像を更新することができます、あるいはあなたは新しいデータが完全に更新されるときはいつでも他のスレッドにシグナルを発行させることができます。