Gauche:サブプロセスでインタプリタ
Shiro(2007/10/06 01:47:38 PDT): 別プロセスでSchemeコードを実行したいことがある。 素直なのはsys-forkだけど、ちょっと問題がある。
- Windows (MinGW, MSVC) では使えない。cygwinは相当器用なことをやって forkを実現してるけど、あれを真似する気力は出ない。
- 複数スレッドが走っている時にsys-forkは危険。
で、もともとの要求として本当にforkのセマンティクスが必要になるとは 限らなくて、単にSchemeのコード片を別プロセスで実行できればいいだけって 場合も多い。要するに (run-process '("gosh") ...) 的なことをすれば いいのだけど、まじめに考えると案外厄介だ。
- 現在走っているgoshと同じバージョンが走ることを保証するには? 現在実行中の バイナリのパスを取るポータブルな方法はない (OS依存の方法を使い分けるなら可能だが)
- libgaucheは他のプログラムにembedされることがあるから、「現在走っている」のが
goshとは限らない。
- libgaucheを使って、拡張したスクリプティングエンジンが作られている場合は、 自分自身を走らせたいかもしれない。
- libgaucheがアプリケーションに組み込まれている場合は、アプリケーションをもうひとつ 立ち上げるのではなく、同じバージョンのlibgaucheを使ったgoshを走らせたいかもしれない。
一方で、これが出来ると、この上に色々面白い機能が作れそうだ。
- stdioをうまくワイヤリングしてやれば、eval-in-subprocessみたいなことができる。
- さらに、別プロセスの場合相手がリモートマシンにあっても良い。eval-in-subprocessは シームレスにローカルとリモートのプロセスをハンドリングできるだろう。
- さらに、別プロセスとその入出力をうまく「eval context」としてパッケージ化してやり、 evalの第二引数を単なるモジュールだけでなくeval contextを取るようにすれば、 普通のevalでin-process, out-process/local, out-process/remoteのevalが 実現できる。
- そうするとその上に簡単に分散プログラミング環境がつくれるかも。
もっとも、これをロバストにやるにはread/writeで確実にデータがやりとりできる 仕組み (CLの*print-readably*みたいなやつ) も仕込みたい。
しばらく考えていたんだが、ちゃんと実装しようとすると結構手間がかかりそうなので、 アイディアだけ書き付けておく。