0

10 ～ 25 ミリ秒ごとに到着するパケットを分析する Tkinter/ttk アプリがあります。現在の実装では、ソケットが読み取られるたびに 30 個の StringVars を更新するスレッドを使用し、update_idletasks() を呼び出して対応するエントリ ウィジェットを更新します。アプリが起動してから 30 分も経たないうちにクラッシュします。

検索の結果、Tk は実際にはスレッドセーフではないことがわかりました。主な選択肢は 2 つあります。

  1. スレッド + キューを使用します。

  2. 関数 + .after(1, 関数) を使用します。

UI は、更新を開始/停止し、表示用の Entry ウィジェットを提供するだけです。

システムでの主な待機はソケットの読み取りで、これには予想されるパケット レートの 2 倍のタイムアウトがあります (したがって、永久にブロックすることはできません)。

この場合、アプローチ 1 と 2 のどちらを選びますか?

私はその単純さのために＃2に傾いていますが、その道に沿って待っているTkの落とし穴があるかどうかはわかりません. コミュニティの知恵を待っている間、おそらく両方を試してみます.

4

2 に答える 2

0

元の実装で文字どおり 8 行のコードを変更して #2 (関数 + .after(1, 関数)) を実装したところ、完全に実行されました。したがって、シンプルさと有効性に基づいて＃2が勝ちます。1 コアの 3 ～ 4% を使用して動作します (i5-2500、3.3 GHz)

しかし、matplotlib アニメーションを介してストリップチャートの記録を追加するなど、UI がより複雑になると、キューと別の取得スレッドが必要になる場合があります。でも今日はだめ！

編集:ただし、.after(0, ...): を使用しないでください: 試してみると、UI がロックされました。

于 2013-04-29T16:13:14.807 に答える