2

アプリケーションが特定のプロトコル (実際には FastCGI) を使用するのに役立つライブラリを Linux の C++ で作成したいと考えています。ライブラリはソケット (TCP または Unix) をリッスンし、リクエストを受信して​​ユーザー コードに転送し、ユーザー コードによって生成されたレスポンスを送信します。

ソケットには多くの接続があり、各接続は多くの要求を運びます (おそらく同時に - インターリーブ メカニズムがあります)。ユーザー コード (ライブラリを使用する) は、複数の要求を並行して処理するためにマルチスレッド化される可能性が高くなります。

ライブラリを堅牢にして、使用するマルチスレッドの種類を含め、ユーザー コードに関する想定や要件をできるだけ少なくしたいと考えています。私が理解しているclone()ように、Linuxの関数は、共有メモリ、共有ファイルハンドルなどの有無にかかわらず、数十の異なる方法でプロセスをフォークできます。マルチスレッドを実装する方法の決定は、ユーザーに任せるべきです。

そして、これは私を混乱させます。なぜなら、ライブラリ コードが突然fork()'ed' になっていることに気づき、コードの複数のコピーが突然同じソケットから読み取られ、同じ要求を処理する可能性があるからです。さらに悪いことに、親プロセスが終了し、子プロセスだけが残り、それがさらに多くの子プロセスを、おそらく別のプロセス名前空間で生成する可能性があります。これは混乱です。

同じ外部リソース (ソケット) にアクセスする必要がある同じコードのすべてのコピーを調整するのに役立つ Linux 機能は何ですか? そのようなスレッドセーフなライブラリを実装する標準的な方法は何ですか? 自分でスレッド モデルを選択し、それをライブラリの利用者に課す必要がありますか?

4

2 に答える 2

0

直接使用しないでください(のようなスレッド化ライブラリの実装clone者に予約cloneしてください)。多くの-sを使用しないでください(おそらくなし)。-sを使用して移動します。pthreadforkpthread

libonionライブラリの設計を見ることができます。これは小さく、HTTP サーバー プロトコルを実装しているため、目標に非常に似ています。

libonionリクエストのスレッドを作成するかしないかのさまざまなモードをユーザーに提供します。

libonionFastCGI リクエストごとに新しいスレッドを作成するかどうかについて、-sと同様のオプションを使用できます。

libeventやlibev ( poll(2) -ing ループの周り)などのイベント ループ ライブラリを使用することもできます。

また、コーディングを開始する前に、優れた本、特にAdvanced Linux ProgrammingとPthread -sに関するいくつかのチュートリアルを読んでください。

また、目標に似たいくつかのフリー ソフトウェア ライブラリのソース コードを調べてください。

于 2012-11-11T14:41:24.357 に答える
-1

一見的外れに見えるかもしれませんが、fastcgi をプロセッサごとに 1 つのスレッドで実装することをお勧めします。

理由:

  1. より堅牢。
  2. マルチスレッドに関連するコンテキスト切り替えのオーバーヘッドを回避し、同時実行デッドロックなどの問題から保護します。
  3. プロセス fork() のコストを回避し (すべての合計は非常に軽いですが)、他の頭痛の種の中でも潜在的な子ゾンビ プロセスの処理から保護します。

これにより、以下を使用して fastcgi インターフェースを実装する選択肢が残ります。

  1. ノンブロッキング同期 I/O ( Reactor設計パターン): 読み取りまたは書き込み要求が来るまでブロックし、要求を適切なハンドラーに渡し、次の要求が来るまでブロックします。
  2. 非同期 I/O ( Proactor設計パターン): O/S が I/O 完了イベントをサポートするオペレーティング システムに読み取りおよび書き込み要求を渡します。Windows ではIO 完了ポート になり、Linux ではepoll()のようなものになります。
于 2012-11-11T15:01:50.253 に答える