しばらく前にhabrで、HabrUser qmaxからの「継続」に関するトピック が滑りました 。 彼はこのアイデアに非常に感銘を受けましたが、詳細を伝えることはできませんでした。 そして最近、Seasideの開発者の一人であるJulian Fitzellは、その明快さに関して驚くべき記事を書きました。 彼の許可を得て、私はそれを翻訳し、habrasocietyと共有したいと思います。



すぐに用語について言いたいと思います。 継続という言葉の翻訳として、「継続」という意味で最も近いものを使用します。 Smalltalkの経験の浅い開発者向けの記事の一般的な用語は、珍しいように思えるかもしれません。 したがって、呼び出しスタックの代わりに「コンテキストのチェーン」が使用され、スレッドの代わりに「プロセス」が使用されます。 読んでもまだ質問がある場合は、コメントで自由に質問してください。 ありがとう



これは、Seasideの今後のリリースに関する一連のレビューの2番目の投稿です。 例外処理に関する最初の投稿をご覧ください 。

シーサイドに続く

シーサイドは「継続ベース」のWebフレームワークと呼ばれることが多く、実際、開発の夜明けには、魔法を描くためにあらゆる場所で続編が使用されました。 Seaside 2.8は、次の3つの異なるケースでファーストクラスの拡張機能を使用します（後で説明します）。

• 要求の処理を停止し（要求）、すぐに応答を返します（応答）。
• コードの実行を中断し、ユーザーがリンクをクリックした後、またはリダイレクトをたどった後に続行する（たとえば、ユーザーのCookieを設定する）
• コンポーネントの呼び出し/応答スキームを実装します。

ただし、Seasideの今後のリリースでは、フレームワークのコアでの拡張機能の使用が完全に排除されます。 これらのケースの最初のケースは例外を使用して再実装され、2番目と3番目のケースのコードはオプションですが、インストールパッケージで利用可能になります。 つまり、継続をまったく使用せずにSeasideをインストールできます。 この事実は、現在継続をサポートしていないSmalltalk方言間の移植性を改善するはずです。



同時に、ファーストクラスの拡張機能も部分的な拡張機能に置き換えます。この記事では、これが何を意味するのか、なぜこれらの変更を行うのかを説明する必要があります。 これはすべて、（特にデバッグ中に）バーを下げる可能性があるため、心配する必要はありませんが、情報を落ち着かせてから、それに戻って読み直してください。 続編のアイデアそのものに困惑している人々がこのトピックをより理解しやすいものにすることを期待して、詳細を犠牲にしていくつかのことを簡略化しました。 このバランスをどのように維持したかについてのフィードバックを受け入れます。

続編とは？

まず、継続について言及するとき、私は最初のクラスの継続を意味します。 Seasideは、継続転送メソッドを使用してレンダリングサイクルを実装します（これは、Seasideによって生成されたURLに表示される_kパラメーターです）。 これは密接に関連する概念ですが、これから説明するものではありません。



継続はしばしば「残余計算」として定義されますが、この現象の本質をまだ理解していない場合、これは少しあいまいな定義であると思います。 私にとって最も簡単な説明は、継続によって実行中のプロセスの「スナップショット」が保存され、後で継続できることです。 別のメソッドを呼び出す別のメソッドを呼び出すメソッドを呼び出します。その後、この一連の呼び出しのスナップショットを取得し、スナップショットオブジェクトをどこかに保存します。 将来、現在実行中のコードを破棄することでいつでも復元でき、プログラムはその場所から、「スナップショット」に記録された方法から実行を継続します。 これは、最初のクラスの続きです。



Smalltalkユーザーは、Smalltalkイメージを保存して後で開くと、保存時とまったく同じ画像が表示されるため、理解しやすくなっています。 保存した画像は何度でも開くことができ、そのたびに同じ状態に戻ります。 イメージを新しいファイルに保存すると、古いファイルに戻ることができます。 継続は、原則として、画像全体ではなく同じことを行い、唯一のプロセスを保存します。

「通話と応答」の実装

Seasideの最も素晴らしい機能の1つは、通常の反復スタイルでユーザーの参加を必要とするマルチステップタスクを作成する機能です。

answer := self confirm: 'Do it?'.

answer ifTrue: [ self doItAlready ]



これは、継続を使用する場合に簡単になるものです。メソッドの途中で停止し、ユーザーに情報の入力を求めます。 彼が答えたら、中断したところから実行を続けたいと思います。 それでは、これを実現するためにファーストクラスの拡張機能を使用する方法を見てみましょう。

チャートの読み方

小さな余談。 次の図は、コンテキストチェーンを示しています（ただし、それらはフレームスタックと呼ばれるほど抽象的です）。 メソッドを呼び出すたび、またはブロックを実行するたびに、チェーンの「上部」に新しいコンテキストが作成されます。 メソッドが値を返すか、ブロックが終了するたびに、「上」からのコンテキストが削除されます。 メソッドのコンテキストは、どのメソッドがそれを呼び出したか、どのオブジェクトが呼び出されたか、およびこのメソッドで定義された変数の値を知っています。 彼はまた、チェーン内の彼の下のコンテキストを知っています。 このプロセスを理解するのに助けが必要な場合は、イラストをご覧ください。すべてが段階的に描かれています。











次の図は、単一のHTTP要求を処理するためのコンテキストのチェーンを表しています。 各リクエストは、コールバックを生成するリンクをクリックした結果です。 各コールバックは、最終的に#call:



または#answer:



送信します#answer:







図は、 #call:



または#answer



ときにコンテキストのチェーンを示し、次に何が起こったかを示しています。 上矢印はメソッドを呼び出したときの進行状況を示し、下矢印はメソッドが完了したときを示します。 例外を破線の矢印の形で示します。その尾は例外の発生場所にあり、頭はその処理の場所を示しています。 継続が保存される場合、両方のチェーンがダイアグラムに表示されます。現在実行されているチェーンと保存されているチェーン。 矢印は通常どおりに向けられます。 明らかに、これらは非常に簡略化された図です。具体的な詳細よりも一般的なアイデアを説明することに興味があります。



明確にするために、各チャートに灰色のバーがマークされています。 その上にあるのはユーザーコードです。実行されるコールバックの一部です。 行の下にあるものはすべて、フレームワークの一部です：ソケットからの読み取り、セッションの管理など。

ナイーブ（fr。）実装

さて、継続を使用して可能な実装の1つを見てみましょう。 ユーザーが「do it」リンクを含むWebページにいるとします。 リンクをクリックすると、例として上記のコールバックが実行されます。ユーザーは「Do it？」と尋ねる必要があります。 この要求を処理する過程で、次のことが発生します。

1. フレームワークは正しいコールバックを検索して実行します。
2. コールバックの実行中（上記の例の#inform：メソッド内）、メッセージ#call:
   
   
   
   送信されます。
3. 各コンテキストの結果は、継続使用のために保存されます。
4. コールバック処理を停止し、制御をフレームワークに返す例外がスローされます。
5. フレームワークは引き続き動作し、応答をブラウザーに返します（Seasideでは、応答のコンポーネントを表示するためにレンダリングフェーズが実行されますが、ここでは少し簡略化します）。

その結果、ブラウザには「Do it？」プロンプトとアクションを確認するリンクまたはボタンが表示されます。 ユーザーがこのリンク（またはボタン）をクリックすると、コールバックがアクティブになり、 self answer: true.



が実行されself answer: true.



。 そして、2番目の要求が受信されると、次のことが起こります。

1. フレームワークは、対応するコールバックを検索して実行します。
2. #answer:
   
   
   
   は#answer:
   
   
   
   メッセージを送信します。
3. 現在のコンテキストのチェーンは破棄され、継続で保存したコンテキストはその場所に復元されます。 このメソッドは2回目に返されることに注意してください。 これはもちろん奇妙ですが、コンピューティングの最中にSmalltalkイメージを保存することほど奇妙ではありません。 画像を開くたびに、同じ計算の結果が表示されます。
4. 前のコンテキストチェーンを復元したので、 #call:
   
   
   
   継続を保存した場所）への呼び出しが#call:
   
   
   
   したかのように、最初のコールバックで実行が継続されます
5. 復元されたコールバックは実行を完了します（この例では、ユーザーの応答の値をチェックし、 #doItAlready
   
   
   
   を送信し#doItAlready
   
   
   
   ）
6. フレームワークは、ブラウザーに応答を送信します。

しかし、問題があるため、この実装をナイーブと呼んでいます。 ご覧のとおり、最初のリクエストで答えが誤って返されます。 残念ながら、最初のリクエストに関連付けられたソケットは長い間閉じられており、ブラウザは回答を待っていません。 ブラウザは、明らかにリクエスト番号2に関連付けられたソケットに到達しない回答を受け取ることを期待しています。 おっと！

（ほぼ）作業中の電話と応答

したがって、最初の実装は機能しませんが、続編に何が起こるかを示してくれることを望みます。 問題は、継続を復元するときに、フレームワークが行ったすべてを絶対に捨てたくないことです。 少なくとも、正しいソケットに応答を返すコンテキストが必要です。



継続によってキャプチャされるコンテキストの数を制限する簡単な方法は、新しいプロセスを作成することです。 新しいプロセスは、新しい空のコンテキストチェーンから始まります。そのため、継続を作成すると、このチェーン内のコンテキストのみがキャプチャされます。 セマフォを使用して、新しいプロセスがリクエストを処理している間、最初のプロセスを待機させることができます。 2番目のプロセスが完了すると、セマフォに点火し、元のプロセスは正しいソケットに応答を返します。



次の図は、この図を示しています（異なるプロセスのコンテキストは異なるシンボルで表されます）。

1. フレームワークのコードのある時点で、新しいプロセスが作成され、元のプロセスはセマフォ信号を予期します。
2. 新しいプロセスは、リクエストに対応するコールバックを見つけて実行します。
3. #call:
   
   
   
   はメッセージ#call:
   
   
   
   送信します#call:
   
   
   
   
4. 継続は保存されます（今回は継続が新しいプロセスの開始点から開始することに注意してください）。
5. 例外がスローされ、コールバックは処理を停止し、制御をフレームワークに返します
6. フレームワークは、ブラウザーの応答を作成し、セマフォに点火します。
7. 元のプロセスが続行され、ブラウザーに応答が返されます。

これまでのところ、唯一の利点は継続が少ないことです。 しかし、2番目のリクエストが到着すると、このアプローチが問題をどのように解決するかが明らかになります。

1. フレームワークのコードのある時点で、新しいプロセスが作成され、元のプロセスはセマフォ信号を予期します。
2. 新しいプロセスは、リクエストに対応するコールバックを見つけて実行します。
3. #answer:
   
   
   
   は#answer:
   
   
   
   メッセージを送信します。
4. 現在のコンテキストのチェーンは破棄され、継続で保存したものが復元されます（ただし、今回は生成されたプロセスのコンテキストのみが破棄され、保留中のプロセスは影響を受けないことに注意してください）。
5. 保存されたコンテキストチェーンを復元した後、 #call:
   
   
   
   の呼び出しが#call:
   
   
   
   したかのように実行が続行されます。
6. コールバックは実行を完了します。
7. フレームワークはブラウザの応答を作成し、セマフォに点火し、親プロセスに作業の完了を通知します。
8. 元のプロセスは実行を継続しますが、今回はブラウザに正しく応答を返します。

これで、継続が小さくなっただけでなく、2番目の要求に対する応答が意図したとおりに返されるようになりました。 Seaside 2.8以前で使用されたのはこの実装です。



しかし、いくつかの重大な問題があります。

1. プロセス間通信を作成すると、システムの複雑さが増します。
2. 例外は、新しいプロセスが作成された境界を越えることはできません。 実際、例外をスローすると、最初のプロセスはそれを知ることはありません（技術的には乗り越えられ、ある程度この動作をシミュレートできますが、これはシステムをさらに複雑にします）。 これは、生成されたプロセスでエラー処理を完全に実行する必要があることを意味します。 これにより、たとえば、例外を使用してオブジェクトを「ダーティ」としてマークしたり、現在のプロセスのトランザクションステータスを示したりするデータベースを操作する場合にも、困難が追加されます。
3. 復元の続行後にスローされた例外は、復元されたコンテキストのチェーンを通過します。 また、例外が処理されると、コンテキストの復元されたチェーンは巻き戻され、スローされたものではありません。 最後の図の赤で色付けされたフレームワークコンテキストを見てください。実行を完了する機会がなく、それらによって定義されたすべての安全ブロックが実行されることはありません。 これがいくつかの陰湿なバグを引き起こす可能性があると言うとき、私を信じてください。
4. ポイント2と3に関して、 サイズと精度の妥協点を探す必要があります。コールバックを実行する直前に新しいプロセスを開始すると、非常に小さな継続とより短い例外処理が得られます。 残念ながら、例外を十分にスローすることはできず、コードは完全に異なる場所、たとえばレンダリングフェーズで実行を終了します。
5. コードが実行中のプロセスに依存している場合、 デバッグは悪夢になります （少なくともSqueakでは）。 デバッガーがエラーが直接発​​生したプロセスに進む方法を学習するかどうかはわかりませんが、少なくともエラーなしでこれを行うことはできません。

部分継続

部分的な続編は、コンテキストのチェーン全体を保持する代わりに、関心のある部分のみを保持することを意味します。 そして、部分継続を復元する場合、チェーン全体ではなく、関心のない部分のみを置き換えます。 それがどのように機能するかを見てみましょう。









最初のリクエストが到着すると、すべてが最初の例とまったく同じように発生するため、段階的な分析は行いません。ただし、1つを除きます：部分的な拡張子を使用して、継続で保存するコンテキストの正確な範囲を指定できます。 この場合、ユーザーコードの一部であるコールバックのみを保存します。 最初の実装の問題を覚えていますか？ フレームワークコードは1つの特定の要求を処理します。 これらのフレームワークコンテキストは、他のリクエストを処理する際にはまったく役に立ちません（同じURLであっても、新しいリクエストがあります）。 コールバックは実行中に複数のHTTPリクエストをカバーできるため、将来の復元のためにこれらの（リクエストに応じて）コールバックコンテキストのみを保存する必要があります。



また、実際のコンテキストチェーンはこれらの図に示されているよりもはるかに長くなる可能性があることを忘れないでください。したがって、たとえば40の代わりに5つのコンテキストを保存します。 まあどう？ 良い節約。



次に、2番目のリクエストがどのように処理されるかを見てみましょう。 この図は、実行時にコンテキストのチェーンが変化するため、少し異なり、より複雑です。そのため、ステップごとに説明します。

1. 要求は処理中です。
2. フレームワークは適切なコールバックを検索して実行します。
3. #answer:
   
   
   
   は#answer:
   
   
   
   メッセージを送信します。
4. 次に、既存のコールバックコードの代わりに保存された部分継続が検索され、保存されたコンテキストが現在のコンテキストに文字通り「移植」され、メッセージ送信者が書き換えられます。 私は空中で手を動かし、細部を省きますが、あなたは私を信じなければなりません、すべてが実際にそのように起こります。 図の右側は、「移植」の完了後の状態を示しています。 フレームワークのすべてのコンテキストは影響を受けず、元のプロセスにあることに注意してください。
5. 保存されたコールバックの実行は、 #call:
   
   
   
   メソッドの呼び出しが終了したかのように継続します。
6. 復元されたコールバックが実行を完了するとすぐに、現在の要求を処理するフレームワークコードに直接制御を返します（送信者を置き換えたため）。
7. 次に、応答が生成され、適切なソケットを介してブラウザーに送信されます。

魔法！ 私はそれがそのように見えると確信していますが、それはうまく機能します。 その結果、短い続編があり、新しいプロセスを作成する必要がなく、すべてのフレームワークコードが実行を正常に完了する機会を得ます。

おわりに

部分的続編の決定は、現在Seasideの開発バージョンに実装されており、次のリリースに含まれます。 SqueakとVisualWorksは、すでにコードの部分継続の実装をサポートしています。 GemStoneは、VMでの実装をほぼ完了しています。 部分継続を実装できない方言には、選択肢があります。

• 最初のクラスの拡張機能を使用して、さまざまな程度の完全性を持つ部分的な拡張機能をシミュレートできます。
• Seaside 2.8のシステムと同様のシステムを引き続き使用できます。
• それらを放っておくことができます。 上記で述べたように、継続とSeasideカーネルの使用を削除しました。プラットフォームはcall #call:
  
  
  
  サポートを停止できます。これは簡単になり、Seaside-Flowパッケージを提供しなくなりました。

これが有用で興味深い読み物であり、複雑で理解しやすいと思われるすべてについてのコメントに感謝します。 ハッピーシーサイド。