zeroMQ （知らない人にとって非常に便利なソケットの代替品）を調べているときに、メーリングリストでこの質問に出くわしました。
複数のコンテキストを使用する：複数のコンテキストを使用することの欠点はありますか？
複数のコンテキストを使用することの欠点はありますか？できるだけシンプルにしておきたいクラスラッパーがあります。単一のコンテキストで複数の接続やソケットなどを許可するように変更するか、そのままにしてラッパーのクライアントに複数回インスタンス化させることができます。
私が見ているように、2つの欠点があります。
- リソースを無駄に拘束する（余分なメモリフットプリント、別のI / Oスレッドなど）
- 異なるコンテキストで作成されたソケットは、「inproc」トランスポートを使用して相互に通信できません。「inproc」という名前は少し誤称です。それは本当に「イントラコンテキスト」を意味します。
cr
私と他のさまざまなソースコードを振り返ると、最終的にコンテキスト設定コードが次のようになっていることに気付きました。
void *context = zmq_init (1); //creates the context
void *responder = zmq_socket (context, ZMQ_REP); //creates the socket
zmq_bind (responder, "tcp://*:5555"); //and binds it
... //Do whatever you want with the socket ...
zmq_close (responder); //destructors
zmq_term (context);
効果的に次のように置き換えることができます：
void *context = zmq_init(1); //saving the context is optional
responder = zmq_socket(type); //creates the socket
//additional [context] can be provided if desired (multi-context?)
zmq_bind (responder, "tcp://*:5555"); //and binds it
... //Do whatever you want with the socket ...
zmqx_dest(); //destroys the global context, else provide alternative [context]
そして、それは私がマクロでしたことです。これにより、追跡する変数が1つ少なくなります（他の100個のうち）。マクロが同じ「関数スコープ」内にある必要があるため、「理想的」にはほど遠いですが、これは簡単に解決できます。
私の例はCですが、これは言語に依存しません。
したがって、質問、そのようなコンテキストを作成することのポイント/利点は何ですか？
そのような機能を許可することの実際の欠点はいつですか？原因私は多くの人（コードをコピー/貼り付け/編集するだけ）を簡単に予測でき、余分なオーバーヘッドを考慮せず、必要のないときに「たくさんのコンテキスト」を作成できます[他の同様の構造で何度も見られますが、それらの存在はそれ自身の正当化]
私がこれを言っている理由の1つは、初心者のゲームプログラミングモジュールでzeroMQの使用を検討しているという事実です。かなりの部分はその単純さ、そしてソケットが新しい人のために脳細胞を揚げる傾向があるという事実のためです。
ランダムに、私は実際にグーグルのV8コンテキストシステムの理論的根拠を正当化しました（同様の質問;異なるシステム）： HandleScopeの背後にある設計の理論的根拠は何ですか？