Gauche:プロセスを越えたlambdaの移送
nekoieより。
- プロセスを越えてlambdaとそのクロージャ(この表現で合ってるか怪しげ)を 共有したいので、何とかして、変数にバインドされている中味のlambdaを ファイルやdbに書き出したり、それを読み込んだりしたい。 でも、やり方が分からない。
- 今朝この話を見て、出社する途中で考えてたんですが、 単に環境フレームだけでなくコンティニュエーションフレームなんかも含めて必要ではないですか? scheme処理系が「今走っている自分自身のプロセスイメージ」みたいなのをファイルに dump(S式が理想だけどボリュームがどうだろう)できて、 一方それを読み込んでスレッドを再生するなどという”墓場に入ったはずの死体を引きずり出して仕事が出来る様に立ち上げる”的なことが出来れば、 可能なのかなと思いましたが、なんか書きながら実現できるのか?って感じですね。。。 言うのは簡単なので言うだけは言いますけど。。。(^^;;すみませんcut-sea:2003/08/20 16:47:11 PDT
- dump する関数自身も呼ばれたらスタックフレームを作ってしまうわけで、結局 C レベルで完全に実装できないとダメな気がします。 コアダンプ(しちゃ困るけど)みたいな事が自力で出来れば、時間的(場合によってはネットワークごしにという意味で空間的)に ずれた世界を走っている scheme プロセス同士がファイル(広い意味ではポートでいいけど)を通してやり取り可能な道が開けるかも。cut-sea:2003/08/20 16:47:11 PDT
Shiro (2003/08/19 13:42:03 PDT): 通常のlambdaのセマンティクスは、単一のlambdaだけを 簡単に永続化できるようなものではないです。最悪、たくさんの環境を ぞろぞろ引きずることになります。このような分散環境めいたものを 実現するなら、分散環境に適した新たな移送可能手続きのセマンティクスを 設計・実装するのが良いと思います。
たとえば、lambdaのかわりにplambda (portable lambda)というマクロを書いて、
(plambda (x y) ...)
みたいに作ったクロージャは永続化・移送可能にするとか。
plambdaでポイントになるのは、副作用のセマンティクスをどうするかです。 副作用を全面禁止することにすれば、非常に楽になりますが。 あとは、ランタイム依存のオブジェクト (ポート等) へのアクセスを どう捕まえるかですね。
- Gauche:クロージャの中身を見つつ、副作用全面禁止でちょっと作ってみます。 -- nekoie (2003/08/20 16:20:43 PDT)
nobsun (2003/08/19 18:13:53 PDT) 適用時に実行するアドレス空間を指定できるようにするというのは どうでしょう。papply! とかを用意して、第一引数にアドレス空間を指定するとか。そうすると副作用の問題やランタイム依存の問題もすっきりするかも。
Shiro (2003/08/20 01:51:11 PDT): 「アドレス空間」とは具体的に何でしょう?
- IP address と Process ID の対(俺定義です ^^; nobsun)
通常のlambdaのセマンティクスでは、lambda作成時のlexicalな環境を 取り込んでしまい、それは他のクロージャと共有されているわけです。 その後、ひとつのクロージャが例えばネットワーク越しの別マシンの 別プロセスに移送されると、共有のlexicalな環境を維持するのは高くつきます。
作成時のlexical environmentのスナップショットを作り、作成された クロージャだけがその環境を保持することにすれば、環境ごと渡せば 良いので楽になります。ただその場合は、クロージャの作成時にそういう 特別なクロージャであることをコンパイラが知る必要があります。 (でないと、コンパイラは通常のlexical環境を参照するコードを 出してしまうため)。
副作用が全く無ければ、環境を共有してもコピーしてもおなじことなので 問題無いんですが。
- 副作用はそもそもどこで起きるかが重要でしょうから、その場合、適用時に明示的に指定する方がよいような気がします。また、lambda の外側の環境を暗黙に共有しない方がわかりやすい気がします。2003/08/20 13:02:32 PDT (nobsun)
- plambda を使うのだから暗黙じゃないな。
SHIMADA (2003/08/20 08:22:12 PDT) 自由変数を含まない、単なる手続きオブジェクトだったらどうなるんでしょう。 それでも最低限トップレベルの環境は必要かな。
nekoie (2003/08/20 09:27:11 PDT): なるほどです‥‥。
実は、自分がやりたかったのは、 なんでも継続 に書かれている、Yahoo! Storeの 『アプリケーションは継続をクロージャにラップしてセッションIDをキーとするハッシュテーブルに登録しておき、httpサーバはユーザーからのフォームのsubmitがあるとセッションIDを元に登録された継続を呼び出す』 を、実装したかったのです。 が、コレを普通にapacheのcgi+goshで実装しようと考えても、 ブラウザからのリクエスト毎に終了してしまうので、 次のリクエストを受け取ったcgiが前の継続を憶えていないので、 実装できないと思ったのです。 Paul GrahamはLispで実装したhttpd上で構築したので、 リクエスト毎に継続が無くなる事は無かったのですね。 (それでも、httpdを再起動したりすると、再起動前のセッションは 無くなってしまうようにも思えますけど) (‥‥って、継続とlambdaは別物ですね‥‥。すいません)
Shiro (2003/08/20 12:48:09 PDT): persistentな継続というのがあれば便利だなという ことは考えられていますが、ちゃんと動かそうとするといろいろ大変だと 思います。"process migration" あたりで探すといろいろ出てくるんでは。 10年くらい前に大学院の同期が、コンパイラに手を入れてCプログラムを 移送可能にするみたいなことをやってました。