5
私は、pthreadを使って重いバックグラウンド処理を行うGUIアプリケーションを持っています。pthreadsを使用するときのバックグラウンドスレッド（nice、priority）
バックグラウンド処理が実行されている間、GUIは非常に反応が遅く、バックグラウンドスレッドによってCPU時間が枯渇しているためです。
Windowsでは、:: SetThreadPriority（hThread、THREAD_PRIORITY_BELOW_NORMAL）をバックグラウンドスレッドで実行できます。すべてうまくいきます。
しかし、Linuxではpthreadsを使用していますが、良い選択肢が見つかりません。
私は既に考えています。
- ::はsched_setscheduler（SCHED_FIFO）または::はsched_setscheduler（SCHED_RR） - それはルート（私のGUIアプリケーションのための素晴らしいではない）を必要として、これは実行可能でない - また、これはGUIのスレッドを行いますがあまりにも多くのCPUを持っています;私はバックグラウンドスレッド上でGUIに優先順位を付けたいだけです。
- :: pthread_setschedparamのが、サポートされていないSCHED_FIFOまたはSCHED_RR以外の使用（::はsched_get_priority_min（SCHED_OTHER）と::は、sched_get_priority_max（SCHED_OTHER）の両方の0を返す）
- は、複数のプロセスがあり、使用::素敵。これを実行可能にするには、GUIとバックグラウンドスレッドの間の結合が大きすぎます（この設計に多くのコードを移植することは、大量の作業です）。
- :: setpriorityを使用してバックグラウンドスレッドを再調整します。これは動作しません - しかし、ドキュメントが言うことに対して直接である：（システム全体の後日ので、潜在的に「固定」することができる）PThreads documentation私は、これはGUIアプリケーションのための非常に一般的なパターンがあることを確信してい
私は何を逃したのですか？
Marcus。
EDIT：役立つかもしれない高いものにバックグラウンドスレッドのnice値を設定するオプション（感謝ZalewaPL）
「GUIとバックグラウンドスレッド間* ...あまりにも多くのカップリングを... *」私はオーバーデザイン、SRYを考え始めるだろう。 – alk
UIとバックグラウンドスレッドの間に多くのトラフィックを持たない理由はありません。これをクロスプロセス通信に移植したくないのはかなり妥当です。 –