Gauche:プロセスを越えたlambdaの移送

Gauche:プロセスを越えたlambdaの移送

nekoieより。

Shiro (2003/08/19 13:42:03 PDT): 通常のlambdaのセマンティクスは、単一のlambdaだけを 簡単に永続化できるようなものではないです。最悪、たくさんの環境を ぞろぞろ引きずることになります。このような分散環境めいたものを 実現するなら、分散環境に適した新たな移送可能手続きのセマンティクスを 設計・実装するのが良いと思います。

たとえば、lambdaのかわりにplambda (portable lambda)というマクロを書いて、

  (plambda (x y) ...)

みたいに作ったクロージャは永続化・移送可能にするとか。

plambdaでポイントになるのは、副作用のセマンティクスをどうするかです。 副作用を全面禁止することにすれば、非常に楽になりますが。 あとは、ランタイム依存のオブジェクト (ポート等) へのアクセスを どう捕まえるかですね。

nobsun (2003/08/19 18:13:53 PDT) 適用時に実行するアドレス空間を指定できるようにするというのは どうでしょう。papply! とかを用意して、第一引数にアドレス空間を指定するとか。そうすると副作用の問題やランタイム依存の問題もすっきりするかも。

Shiro (2003/08/20 01:51:11 PDT): 「アドレス空間」とは具体的に何でしょう?

通常のlambdaのセマンティクスでは、lambda作成時のlexicalな環境を 取り込んでしまい、それは他のクロージャと共有されているわけです。 その後、ひとつのクロージャが例えばネットワーク越しの別マシンの 別プロセスに移送されると、共有のlexicalな環境を維持するのは高くつきます。

作成時のlexical environmentのスナップショットを作り、作成された クロージャだけがその環境を保持することにすれば、環境ごと渡せば 良いので楽になります。ただその場合は、クロージャの作成時にそういう 特別なクロージャであることをコンパイラが知る必要があります。 (でないと、コンパイラは通常のlexical環境を参照するコードを 出してしまうため)。

副作用が全く無ければ、環境を共有してもコピーしてもおなじことなので 問題無いんですが。

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プログラムを 移送可能にするみたいなことをやってました。

More ...