Webサーバーとプログラミング言語の「継続」メカニズムを説明する答えを探しています。
私の理解では、継続を使用すると、明示的なスレッド化なしで、「pi の数字」プロデューサーが「pi の数字」コンシューマーと通信することは簡単です。
Jetty の継続について非常に良いことを聞いています。他の人がどう思うか興味があります。
私はすでに答えを見つけているかもしれませんが、とにかくここで質問しています-記録のために。
Webサーバーとプログラミング言語の「継続」メカニズムを説明する答えを探しています。
私の理解では、継続を使用すると、明示的なスレッド化なしで、「pi の数字」プロデューサーが「pi の数字」コンシューマーと通信することは簡単です。
Jetty の継続について非常に良いことを聞いています。他の人がどう思うか興味があります。
私はすでに答えを見つけているかもしれませんが、とにかくここで質問しています-記録のために。
それらはプログラミング言語に見られる継続とどのように比較されますか?
名前以外に共通点はありません。これは、現在のスレッドの状態を保存および復元するための API を提供することによって現在のスレッドを解放するメカニズムにすぎませんがServlet
、現在のコンテキストから状態が自動的に推測される実際の継続とは対照的に、すべて手動で管理されます。
これが理にかなっている場合の典型的な例は、1 つのサービスが他のサービスに多くのリクエストを行う必要があるレイヤー化された (構成された) Web サービスであり、これらのリクエストが行われている間、現在のスレッドは解放されます。要求が完了すると (他のスレッドで非同期に実行できます)、サーブレットのresume
メソッドが呼び出され、要求の結果から応答が組み立てられます。
このページによると:
継続は、仕様が確定すると、標準の Servlet-3.0 中断可能リクエストに置き換えられます。提案された標準の一時停止/再開 API を実装する Jetty-7 の初期リリースが利用可能になりました
私はまだJettyを使用していませんが、サーバーは継続的にポーリングするクライアントに応答を送信する際にサーバーが「保留」(ブロックしていると思います)している場合、各クライアントのスレッドを保持する必要はないようです。 AJAX を使用すると、スケーラビリティの問題となるクライアントごとにスレッドが必要になります。