クライアント - サーバー GUI プログラム

今日の他の多くのGUIプログラムと同様に、lxterminal2008年以来、ユーザーごとにXごとに単一のプロセスですべての端末エミュレータウィンドウを表示しようとしました。これを行うには、表示された名前（表示名とユーザー名を含む）で既存のソケットに接続しようとします。

• 接続が成功すると、現在のディレクトリと引数ベクトルをソケットにダンプして終了します。開かれたファイル記述子を現在のディレクトリに直接渡すために、ファイル記述子転送を使用せずに名前で渡します。
• 接続が失敗した場合に試みます。それ自体このソケットでリスニングサーバーになります。現在のディレクトリと引数ベクトルを含むメッセージを読み取り、それが現在のディレクトリと引数ベクトルであるかのように、各読み取りごとに新しいGUI端末エミュレーションウィンドウを開きます。

これの明らかな効果は、lxterminal呼び出された最初のプログラム（継続実行）が同期的に実行されるのに対し、2番目以降のプログラムはそうではないということです。これを観察するには、次から行ってください。いいえ lxterminalインスタンス実行中、実行中各種端末エミュレータと電話

lxターミナルと省電力LX端子。

シェルから。シェルは1秒後にプロンプ​​トに戻り、lxterminalまだ実行中の1つのジョブのみを表示します。

rxvtには同様の機能がありますが、サーバーは明示的に呼び出す必要があり、クライアントは明示的に実行する必要がありurxvtdます。urxvtc通常の実行では、urxvtクライアント - サーバーのうなぎを試みません。

GNOME端末ただこれと比較して、このアプローチは効果的です。それいつも引数ベクトルをサーバープロセスに渡して終了します。さらに、すべてのディスプレイ（およびメカニズムが初期化および起動される方法のエラー）を処理するサーバープロセスは、ユーザーごとに1つだけです。

不安定

予測可能な名前でファイルとソケットを生成することは/tmpよく知られているセキュリティ上の問題なので、lxterminal共有してください。ユーザーは、同じシステム上で他のユーザーが実行している予測可能な場所にソケットを事前に作成してlxterminal通信を試みることができます。

代わりに、rxvtは各ユーザーのホームディレクトリのグループ書き込み不可能、その他の書き込み可能サブディレクトリを使用します。この問題を解決する別の方法は、lxterminal他のユーザーがソケットを 。/run/user/username/lxterminal

（GNOME端末はユーザーレベルのデスクトップバスを使用してクライアントとサーバー間の通信を行います。現在のソケットの場所は、AF_LOCAL許可されていない他のユーザーによって置き換えられません。）/run/user/username/

昆虫

GNOME端末を悩ませる問題の1つは、エミュレートされた端末の各インスタンスに対して単一のサーバープロセスで多数のオープンファイル記述子を消費することです。以前は16個でしたが、今は「ただ」8個に減りました。

lxterminal2を使用してください。そのうちの1つは、クライアントプロセスのソケット接続から漏れたオープンファイル記述子です。十分な端末エミュレーションをオン/オフすると、lxterminal最終的に利用可能なファイル記述子が不足します。以下は、lxterminal実行中のインスタンスがない状態で始まり、私のコンピュータの1つでサーバー上の利用可能なファイル記述子のすべてを使用するのに1分かかりました。

(ulimit -H -n 1024;lxterminal)&
シーケンス0 1024 |読み取り時に-ri;実行lxterminal -e /usr/bin/true;

追加読書

• PIDでgeditプロセスを終了できません。
• gnome-terminalの実際のマルチプロセスインスタンスの実行
• フレッド治安（2008-06-16）。 プロセス共有のために欠落しているファイルを追加する。 1f69f854d8ab1377888e18c759f11eae99da75b9。 lxde/lxterminal。 GitHub。
• フレッド治安（2008-06-16）。 プロセス共有サポートの追加。 074ec09b779c0265a316d37742d2957146bcb141。 lxde/lxterminal。 GitHub。