speedygosh

• 概要
• 補足
• 必要要件
• ライセンス
• ダウンロード
• インストール
• 使い方
• 引数
• shebang行での引数指定時の重要な制約(仕様)
• speedygoshモジュール
• on-speedygosh?
• speedygosh-safety-shutdown
• speedygosh-add-termination-handler!
• speedygosh-delete-termination-handler!
• 自作自演faq
• 仕様上の制約
• 一時ファイル
• stderrに対する不完全性
• シグナルに対する不完全性
• 起動関連
• スクリプト関連
• その他
• 動作概要
• 動作の流れ
• 一時ファイルの生成と削除の責任所在
• ベンチマーク
• TODO
• 作った感想など
• バグレポート
• gauche.nightプレゼン

概要

nailgun / speedycgi / perperlの、Gauche版のようなもの。

• http://www.martiansoftware.com/nailgun/
• http://daemoninc.com/SpeedyCGI/
• googlej:speedycgi

要は、各種CGIやscmailのような、「たまにしか実行されない時もあるが、嵐のように激しく連続で実行される時もある」スクリプトを、それなりに高速に動作させる為のツール。

goshの起動オーバーヘッドがperl等と比較するとどうにも結構大きいので、負荷を抑える目的で作成しました。

初回実行時は起動速度は変化しませんが、その際に内部で勝手にバックエンド起動を行い、二回目以降の実行は高速起動されます。一定時間(デフォルト設定では90秒)の間実行されないとバックエンドは自動終了します。

Cで書かれたESTPクライアント部(speedygoshコマンド)と、Gaucheで書かれたESTPサーバ部(speedy_backend相当、つまり常駐プロセス。実体はspeedygosh.server-estpモジュール)の二つによって構成されます。

補足

以前は「speedycgiのGauche用clone」と説明していましたが、これだと語弊があるので説明文を直しました。

「speedycgiのgosh版が欲しい」と思って作ったので、unix domain socketを使うアイデアや利用場面は同じです。 が、基本的には全部自前で書いてますし(sha.cとか除いて)、内部構造はかなり違います(良くも悪くも)。

元々は、speedygoshは、ESTPとestpdを作る最中に完成した副産物でした。

必要要件

• Gauche-0.8.10以降
• unix domain socketが動作する環境
• fcntlによるロックが動作する環境(つまり、nfs等ではない、一般的なfs(とブロックデバイス)が必要になります)
• pipe, select, fork, setsid, stat(のmtime), setenv/unsetenv, 等々が正常に動作する環境(POSIX準拠なら大抵はokだと思われる)

• おそらくmakeは、gmakeでないと上手く動かないような気がします。
• 今のところ、gcc以外でのコンパイルは試していないので、gcc以外ではコンパイルが通らない可能性があります(古いgcc(2.95等)でもアウトかも知れません)。

ライセンス

修正BSD風ライセンスです。 tarball同梱のCOPYINGに詳細(といっても、定型文のみですが)が書いてあります。

尚、同梱のsha.c, sha.hは、Gaucheからもらってきました(public domainと書いてありました)。

ダウンロード

パッケージ

• http://legacy.tir.jp/speedygosh-0.1.9.tgz

リポジトリ(移動しました)

• https://github.com/ayamada/speedygosh

ChangeLog

• https://github.com/ayamada/speedygosh/blob/master/ChangeLog

インストール

gauche-package installに対応しました。

gauche-package install speedygosh-x.y.z.tgz

これで、Gaucheにspeedygoshモジュールがインストールされ、goshがインストールされているディレクトリにspeedygoshコマンドが生成されます。

使い方

基本的には、スクリプトの一行目の「#!/path/to/gosh」を「#!/path/to/speedygosh」に変更するだけです。

但し、speedygoshには、後述の、通常のgoshにはない様々な制約があります。 この制約のどれかに引っかかる場合は使わない方がいいでしょう。

「#!/path/to/speedygosh」行に引数を付ける事で、動作に関する設定を行う事ができます(※osによっては、引数を一つしかつけられないものもあるそうです。注意！)。 具体的には、以下の通りになります。

引数

以下の引数が設定可能です。

• -g --goshpath=...
  • goshコマンドのpathを明示的に指定。
  • デフォルト値は、gauche-package install時に使われたgoshが設定されています。
• -d --sessiondir=...
  • 通信に利用するsockファイル、ロックに利用するlockファイル等を生成するディレクトリを指定。
  • デフォルト値は"/tmp/speedygosh"。
• -p --maxprocesses=...
  • 同一のスクリプト起動条件での最大並列実行数を指定(この数に達すると、それ以上の並列起動はすぐにエラーを返して終了する)。
  • この値を1にすると、例外的に直列実行モードになり、複数のコマンド実行は常に逐次実行される事になる。
    • -p1 -r999999等に設定する事で、擬似的に、簡易estpdとして使えるようになります。
  • デフォルト値は32。
• -r --maxruns=...
  • サーバプロセスは、この回数を実行した後は、安全の為にプロセスを終了する。
  • デフォルト値は1024。
• -t --timeout=...
  • この秒数の間、クライアントからアクセスが無いと、サーバプロセスは自動的に終了する。
  • デフォルト値は90。
• -e --errorlog=...
  • これを指定すると、stderrをクライアントのstderrではなく、このpathで示されるファイルに追加書き出しするようになる。
  • デフォルト値は無し(つまり、クライアントのstderrに出力)。

shebang行での引数指定時の重要な制約(仕様)

• 各種path(--goshpath, --sessiondir, --errorlog)を指定する際に、空白を含むpathを指定する事が出来ません。
  • これを行うには、結構面倒なコードを書かないといけなさそうなので、後回しにします(そして、おそらくこのまま放置される)。
• 各種path(--goshpath, --sessiondir, --errorlog)を指定する際に、「~username」形式の指定を行う事はできません。「/home/username」のように、明示的に指定してください。
  • 調べれば簡単に実装できそうな気はしますが、後回しにします(そして、おそらくこのまま放置される)。
• 数値を指定する引数は、1以上の値のみを受け付けます。
  • maxrunsやmaxprocesses等を無制限にはできません。signed intとして充分に大きい数値を指定する事で代用してください。
• osによっては、shebang行での引数を複数指定できないものがあるそうです(最初の一つだけが有効になるようです)。
  • その場合は、-p1や--sessiondir=/path/hoge等のように、引数が一つになるように指定してみてください。複数の設定を行いたい場合は諦めてください。

speedygoshモジュール

speedygoshプロセスの挙動を操作する為に、いくつかの手続きが提供されます。

(use speedygosh)

によって、それらの手続きをimportする事ができます。

on-speedygosh?

(on-speedygosh?)

• スクリプトがspeedygosh上で動作しているなら#tを、そうでないなら#fを返します。

speedygosh-safety-shutdown

(speedygosh-safety-shutdown)

• 今回のスクリプト実行が完了した後に、サーバプロセスをshutdownします。

speedygosh-add-termination-handler!

(speedygosh-add-termination-handler! thunk)

• サーバプロセスがshutdownされる直前に呼び出されるthunkを登録します。dbm等のclose等に利用できます。
• プロセスがspeedygoshでない場合には、登録したthunkは全く実行されない事に注意して下さい。
• 何回も呼び出す事で、複数のthunkを登録する事が可能です(前に登録したthunkが上書きされて消されるような事はありません)。
  • 但し、同じthunkを二回登録できてしまうので、重複登録に注意してください。
• thunk実行時の、current-input|output|error-portに対する入出力は全く保証されません(with-input-from-port等で上書きして使う分には全く問題ありません)。
• 尚、エラー例外が投げられてサーバプロセスが終了する時には、このthunkは実行されません。エラー例外が投げられてしまわないようにしてください。
• thunkが実行される際の環境変数の状態は、最後にプロセスを実行した時のものが流用されます。

speedygosh-delete-termination-handler!

(speedygosh-delete-termination-handler! thunk)

• speedygosh-add-termination-handler!で登録したthunkを削除します。
• thunkはeq?で比較される為、もしこの手続きを利用する可能性がある場合は予め、thunk自身をどこかに記憶しておく必要があります。
• thunkが元々登録されていなかった場合は何も削除されません。

この他にも、動的にspeedygoshの設定の一部を変更できるような手続きが今後、提供される可能性があります。

自作自演faq

• どうしてFastCGIじゃ駄目なの？
  1. CGIだけではなく、.qmailから起動するscmailのようなものにも利用したかったからです。
  2. FastCGIプロトコルはnphスクリプトに対応していません。諸事情により、nphスクリプトを使いたい場面がありました。
  3. 経験則ですが、FastCGIはプロセスをシグナルで制御する為か、race conditionが発生して複数プロセスが立ち上がった後にしばらくして暇になったプロセスが終了する際に、すんなりと終了してくれずに500が出てしまう事があるような気がします。
     • 詳細は、mod_fastcgiを見て下さい。
  4. FastCGIは永続的に常駐してしまい、これが困る状況がたまにある。
     • 例えば、使用しているサーバのメモリ量が少なく、可能な限り節約しなければならない等。
     • mysql等、外部とソケット通信する場合に、あまりに長い間アクセスが無い場合に接続がタイムアウトとみなされ、勝手に切断されるようなものがあり、それらへの真っ当な対応(リクエストを送り、切断されていたら再接続してから再度リクエストを送る)を実装するのが色々と面倒。
       • ちなみに、デフォルト設定のmysqlの場合、八時間の間通信が行われないと、サーバ側からソケット通信が切られるようになっています。つまり、八時間誰もアクセスしないとこの状態になります。

• FastCGIを見習って、もうちょっとちゃんとしたプロトコルにしない？
  • それをあなたが実装してくれるなら、喜んで採用させてもらいますが、自分で使う分にはESTPで充分なので、多分ずっとこのままです。
  • 一応、それなりに楽にプロトコルを差し換えられるような書き方にはしてあるつもりです。

• 複数プロセスが起動するのはどうにも微妙だ。Lispマシーン的ないじり方ができた方がいい。
  • そんな人の為に、estpdも開発中です。
  • 簡易的に、shebang引数に-p1を設定する事でも、擬似的にLispマシーン的動作になります。本格的に使うにはかなりアレですが。

• mod_speedygoshは？
  • 技術的には何の問題も無く作れると思いますが、今のところ、そこまで速度を追及する必要性が自分にはないので、mod_speedygoshの方は作らなさそうに思えます。
  • もしあなたがそれを必要とするなら、自分で作ってください。そして、完成したら、もしよければここのリポジトリにコミットしてもらえるとうれしいです。アカウントとか用意しますので。

• speedycgiみたいに、サーバプロセス側もCとlibgaucheで実装すれば、exitとかもハンドリングできるから、下の「仕様上の制約」が減るんじゃね？
  • そうですね。でも面倒なので。あなたが実装してくれるなら、喜んで採用させてもらいます。
  • 妥協案: exitをハンドリングする部分だけCとlibgaucheで書いて、実際のサーバ挙動部分は今のschemeコードをそのまま流用する。
  • しかし、どうもサーバプロセス側もCで書かざるを得ない雰囲気になってきた。

• さくらとか、共用サーバでも使える？
  • gaucheをユーザに自由にインストールさせてくれるようなサーバであれば、speedygoshも使えると思います。
  • 但し、共用サーバのhttpdでは大抵、rlimitが厳しい状態でsetrlimitされていると思うので、あまり長く常駐するような設定にすると、rlimit制限に引っかかってプロセスが突然殺されたりするかも知れません。そうでない場合でも、プロセスが常駐するという事は、常駐している時間分だけサーバのメモリを占有するという事になるので、他のユーザの事も考えて設定を行った方がいいでしょう。多分。
  • また、共用サーバで/tmp以下にファイルを置くのは微妙なので、-dオプションでセッションディレクトリを変更した方が良いでしょう。

• これって、別にGauche以外のスクリプト言語にも応用できるんじゃね？
  • はい、そうです。サーバプロセス部分を好きな言語で書けば、その言語で書かれたスクリプトの起動を高速化(常駐化)できます。S式にアレルギーがあるなら、通信プロトコルを変更してもいいでしょう(個人的には、S式は最高なのですが)。作者としてはGaucheが動けば万事okなのでやりませんが。やってみたい人は自由に挑戦してみてください。そして、もっとスマートに書けたら参考にさせてください。
    • 挑戦する際には、引数/環境変数にバイナリデータ/マルチバイト文字が含まれる際には、Gaucheの不完全文字列書式で送られる箇所に気をつけてください。

• 安全なの？
  • いい質問です。
  • 他の多くのフリーソフトと同様に、コード品質についての保証はありません。あなた自身の目で品質を確認する事は可能ですが。とりあえず、これが大前提です。
  • なるべくrace conditionが発生しないように、robustであるように書いてはいるつもりですが、完全に防げている訳ではないので、負荷やリソースが極限に近付くにつれて怪しくなってくるでしょう。ですが、通常の負荷状況ではまず安全だとは思います。
  • (今のところは)コマンド部分(speedygosh)がCで、サーバ部分がGaucheでspeedygoshモジュールとして書かれている為、Gaucheを上書きアップデートしても正常に動作する筈です、speedygoshモジュール部分が消されたりしない限りは。
  • 作者としては、「通常のgoshスクリプトとして安全ならspeedygoshでもまず安全(但し、通常のgoshスクリプトとして既に問題があるなら、speedygoshでは問題が更に増幅されるかも)」と言いたくて仕方が無いのですが、まだあまり利用実績が得られていないので、本当にそうなのかどうかは謎という事でお願いします。
  • もし、なにか安全でない部分/挙動を発見したら、バグレポートの方に適当に書いてもらえると助かります。

• SIGPIPEは流れる？
  • 以下の「仕様上の制約」を見てもらえば分かると思いますが、流れません。
  • 但し、「本来SIGPIPEが流れる原因になったport」は普通に使えなくなる(入力portをreadするとeofが読み取られ、出力portにwriteするとエラー例外が発生する)ので、それへの対処が行わなくてはなりません。

• 一つのコマンドを同時に実行したり、一つのCGIに同時にアクセスしたりしたらどうなるの？
  • 複数のサーバプロセスが起動し、並列にコマンド実行(CGIアクセス)を捌いていきます、並列に実行(アクセス)が行われている間は。
    • 但し、サーバプロセスの数があまりにも多くなると(具体的には、-pオプションの指定値を越えると)、リソースの圧迫を防ぐ為に、新しい実行はすぐにエラー終了するようになります。
  • 実行(アクセス)が少なくなり、同時に実行されなくなってくると、不要になったサーバプロセスは普通にタイムアウト終了します。
  • この挙動が気にいらない場合は、-p1オプションを設定する事で、サーバプロセスを一つだけに限定する事ができます。この時に並列実行や並列アクセスがあった時は、順番に一つずつ処理が行われるようになる為、片方の実行は待たされるようになります。
    • 但し、この状態では、無限ループ等が発生した場合にコマンドの処理が完全に停止してしまい、それ以降に実行したコマンドは全て応答がなくなってしまうので、注意深く運用を行う必要があります。

仕様上の制約

一時ファイル

• デフォルトでは、「/tmp/speedygosh/」ディレクトリに、各種の一時ファイルを生成します(ディレクトリが存在しない場合は勝手に作ります)。
  • このディレクトリはshebang引数によって、変更できます。

stderrに対する不完全性

• stderrは一旦、一時ファイルに書き出されてから、speedygoshコマンド終了時にまとめてstderrとして出力される。その為、stderrへの書き出しタイミングが他プロセスと前後する事がある。また、プロセス実行中にstderrの内容を確認する事は基本的にできない。

シグナルに対する不完全性

• speedygoshプロセスに対してシグナルが送られても、基本的に、それをハンドリングする事は出来ない。
  • speedygoshに対してSIGINT, SIGTERM等が送られてきた場合、常に、speedygoshプロセスはすぐに終了し、常駐プロセス側は入出力の切断のみを受け取る。
• speedygoshから起動したスクリプトは、SIGPIPEが無視される状態になっている。

起動関連

• shebang部分での、goshに対するコマンドライン引数は指定できない(speedygoshに対する引数として解釈されてしまう)。
  • 外部からスクリプトに渡すコマンドライン引数は普通に指定可能。
• インタラクティブ起動は不可。
• スクリプトのロード時に無限ループに入ってしまった場合の救済措置は無し(通常のgoshによるスクリプト実行と同じ)。

スクリプト関連

• スクリプトのボディに直接実行される式を書いたようなスクリプトはspeedygoshでは動かない。main手続きから起動するようにしてください。
  • 複数回実行を前提とする為、スクリプトのボディに書かれた式は一回のみ、main手続きは毎回実行される事になります。
• main手続きを複数回実行させるような事を考慮していない、グローバル変数に対して副作用を起こすようなスクリプトをspeedygoshで動かすと、動作が怪しくなる。
• sys-systemのstdout/stderrへの出力は捨てられる(コマンドの実行自体は正常に行われる)。とりあえずsys-systemは使わない方が吉。gauche.processを使いましょう。
• sys-exit, sys-abortは使用不可(使うと色々と問題が出る)。
• exitは使用可能だが、使用すると常駐は解除され、また、exit時の終了コードは反映されない(0扱いになる)。
  • 終了コードをきちんと返したい場合はmain手続きの返り値として数値を返す事。
• main手続きの返り値として非数値が得られた場合、通常のgoshでは終了コードは70を返すが、speedygoshでは0を返す(速度向上の為)。main手続きの返り値が数値だった場合はその数値が普通に返るので、特に問題は無し。

その他

• スクリプトの設置されたpathがGaucheにとって不完全文字列を形成する時は、おそらく起動する事ができない(未確認)。
• スクリプトがエラー例外を投げて終了した時は常駐を解除して終了する(安全の為)。
  • 但し、スクリプトのmain手続きが非0を返しただけの時は、スクリプトには問題は無いと判断して、常駐を続行する。
• 環境変数とargvに含まれる文字列がGaucheにとって不完全文字列を形成する場合、そこに含まれる不正なバイト列は捨てられる(string-incomplete->complete str :omit)。

動作概要

動作の流れ

クライアント(speedygoshコマンド)サイド

1. クライアント(speedygoshコマンド)が起動される。
2. 引数を解釈する。
3. スクリプトのpath、クライアント起動時のcwd、スクリプトのmtimeを適当に結合したもののsha1 digest値を取る。
   • スクリプトのmtimeを含めているのは、スクリプトファイルの更新チェックを兼ねさせる為。
4. sessiondirが存在していないなら、sessiondirを生成する。
5. 先ほどのdigest値に、カウント値0を追加して、各種ファイルのpathのprefix文字列を生成し、それを使ってロックを試みる。
   • ロックに失敗したら、カウント値を1ずつmaxprocessesまで増やしながら再試行する。
   • 但し、maxprocessesが1の時のみ、ブロッキングモードを使い、ロックが取得できるまで待つ。
6. ロックに成功したら、該当するprefix文字列を持つsocketファイルの存在チェックを行う。
7. socketファイルが存在していないなら、pipeを生成し、forkし、goshコマンドを使い、サーバ(speedygosh.server-estpモジュール)を起動する。この詳細は後述。
   • サーバ起動後、サーバ側からpipeに改行が流れる事が、サーバの起動処理が完了した合図になる。よって、クライアント側はそれまでselectで待つ。
   • サーバが起動するまでの間にクライアントにシグナルが流れた場合(スクリプトが無限ループを起こしている場合等に起こる可能性がある)は、クライアントはサーバプロセスを明示的にkillしてから終了する(無限ループしているかもしれないサーバプロセスを残す訳にはいかない為)(ここの処理がちょっと微妙)。
8. socketファイルが存在しているか、生成されたなら、そこに対してunix domain socket接続を行い、ESTP通信によって環境変数と引数を送信する。その後、stdinをsocketに転送しつつ、socketからreadできるデータをstdoutに出力し続ける。
   • シグナル等によって中断要求が来たら、そこで処理を中断し、ロックファイル等を削除し、クライアントは終了する(サーバは中断しない)。
9. socketからEOFが読み出されたら、最後まで正常終了したものとして、.exitファイルと.stderrファイルの有無を調べる。
   • .exitファイルが存在した場合、そのファイルに記述されている数値を、speedygoshコマンドのexit値として採用する。存在しない場合は0とする。
   • .stderrファイルが存在した場合、そのファイルの内容を、speedygoshコマンドのstderrに出力する。存在しない場合は何もしない。
10. ロックファイル及び.exitファイル等の一時ファイルを削除し、exit値を返し、終了する。

サーバ(speedygosh.server-estpモジュール)サイド

1. speedygoshコマンドから、各種の引数付きで起動される。具体的には大体、以下のようなコマンドで起動される(あとで引数を追加したりする可能性有り)。

   gosh -b -uspeedygosh.server-estp -Espeedygosh-server-boot -Eexit -- \
   script-file session-path-prefix timeout maxruns errorlog
   

   • 尚、起動直前に、このプロセスのstdoutはspeedygoshコマンドが生成したpipeの一つにすげ換えられている。
2. スクリプトファイルをuserモジュールに対してloadする。load時にエラーになったら、そのままエラー内容をstderrに流し、終了する。
3. 正常にloadできたら、unix domain socketを生成し、socket生成まで完了した合図として、stdoutに改行を一つ流し、すぐにcloseする。
4. その後、socketをselectで待機し、要求が来ると同時に先ほどloadしたスクリプトのmain手続きに渡し、処理を行う。
   • mainの返り値が0以外なら、.exitファイルを生成してから接続を切る。
   • stderrはvportによる遅延ファイル生成portとし、何かデータが来た時点で.stderrファイルが生成され、順に保存される。
5. これらの処理が完了したら、処理が完了したという合図として、socket接続をshutdownし、次の接続を待ち受ける。
6. 一定時間しても次の接続が来ない場合は、ロックファイルを生成してロックを行い、socket及び関連ファイルを削除し、ロックファイルも削除して終了する。

一時ファイルの生成と削除の責任所在

• .lockファイルは、クライアントが生成し、クライアントが削除する。
  • 但し、サーバプロセスが終了する瞬間は例外として、サーバプロセスが生成し、サーバプロセスが削除する。
• .sockファイルは、サーバプロセスが生成し、サーバプロセスが削除する。
  • 但し、クライアントがサーバプロセスを緊急停止させた場合は、クライアントが削除する事(まだ未実装)。
• .stderrファイルは、サーバプロセスが生成し、クライアントが削除する。
  • サーバプロセスは安全の為、リクエストを受け取ったらまず最初に、このファイルが存在していたら削除する事(多分まだ未実装)。
• .exitファイルも、サーバプロセスが生成し、クライアントが削除する。
  • サーバプロセスは安全の為、リクエストを受け取ったらまず最初に、このファイルが存在していたら削除する事(多分まだ未実装)。

ベンチマーク

• speedygosh:ベンチマーク

TODO

ここに書いてある以外にも、ソースを「XXX」「TODO」「FIXME」「ToDo」で検索する事(この順で、優先度が高いものとする)。

• サーバプロセスを簡単にまとめてkillできる手段を用意する。
  • しかし、そもそも「サーバプロセスをまとめてkillする」にはsha1ダイジェスト値が必要で、これを生成するにはスクリプトのpathとmtimeと、実行時のcwdが必要になる。なので、もしpathが相対指定だったり、実行時のcwdが分からなくなったりした時には、どうしようもなくなる。だから、これを実現するコマンドを作った場合、まとめてkillするグループ単位はスクリプト単位ではなく、--sessiondir単位にするしか無いと思う。
  • 現状、サーバプロセスが途中で中断系シグナルを受けた時にどういう挙動をするかが微妙に曖昧。確認する必要がある。
    • dynamic-windによって、.sockファイル等のcleanupは行われる筈。
    • それ以外には何が必要？
    • スクリプトの実行最中にシグナルを受けた際の挙動については、speedygoshではなく通常のgoshでもスクリプト側が対処すべきなので、speedygoshは何もしなくて良い(筈)。
  • killする際には、もしサーバがpidファイルを生成する仕様にしていた場合はそれを使い、そうでないなら「ps auxww|grep Espeedygosh-server-boot|grep sessiondirname」等のようなコマンドを実行し、そこからpidを取得するようにする。
• ESTPの仕様で、環境変数や引数は不完全文字列で来る可能性があるので、(string-incomplete->complete str :omit)を通して不完全文字列内の不正バイト列を除去するようにしてるが、もしかするとこの処理は不要かも知れない。
  • Gauche-0.8.9を要求する部分はこの部分だけなので、この処理を外せば、それ以前のGaucheでも問題なく機能する。外すべき？しかし、外して大丈夫かどうかの確認が面倒……。
  • 尚、外す場合でも、クライアント(C)側の都合で、\x80-\xffが存在すれば、それがGaucheにとって認識可能かどうかに関わらず、一律で#*""で囲んで不完全文字列にしているので、string-incomplete->complete自体は必須。外すのは:omitで、string-incomplete->completeが#fを返した時は、元の不完全文字列をそのまま流用する必要がある。
• サーバプロセス起動中にspeedygoshクライアントにシグナルが流され、途中終了する時にrace conditionが起こりそうな部分がある。あとで仕様を考え直す必要がある。
  • どこかで、「Gaucheはシグナルを受けると一旦キューに貯め込み、安全なポイントに入ってからシグナルの処理を行うが、安全なポイントに入る前に何度もシグナルを受けたら非常事態とみなして、緊急停止する」という話を聞いた気がするので、この話の裏を取ってから、これを使って、サーバプロセスを安全に停止させるように実装する。
• 英語のドキュメント用意、及び、ソース中コメントの英語化
• c/speedygosh.c と c/main.c を分離し、c/speedygosh.c の方は、ライブラリ化する。そして、c/main.c の方に、スクリプト引数パーザをつける(speedygosh引数パーザの方はこれまで通り)。
• サーバ側のシグナル終了時のエラーフラグを立てる/見る部分を実装する事(今のところ、エラーフラグを見る部分が、シグナル終了部分の内側にある為、どうにも実装しにくい)。
• speedygoshコマンドがestp通信を試みる前に、事前に、.exitファイルと.stderrファイルのunlinkをするようにしておく必要がある(シグナル中断時にこのファイルが残ってしまう場合があり、残ってしまうと、次のspeedygoshコマンドによる実行後に、それが今回の実行結果と勘違いされてしまう可能性がある為)。
• configure時にデフォルト設定を変更できるオプションを追加。
• 可能なら、何らかの、無限ループ等の対策を入れたい。
  • rlimitを設定するオプションをつける？

作った感想など

• 当初の自分の予想以上にイケてた。
• Cのコード部分が結構ヤバイ。
• speedyperlの影響が思っていたよりも色濃く、今から考えるともっと良い仕様にできた気はする(とは言っても、一から作り直す気力も無いが)。
• やっぱり、tcpとか使って、サーバ越しにこういう処理が出来た方が(plan9風の)未来性があるとは思った。仮想化技術も有効利用できる。速度は落ちそうだけど。
  • 今回の場合、サーバ越しにするとモジュールファイルのやりとりが大変そうだったのでunix domain socketのみの対応にしたような気がする。多分。

バグレポート

• speedygosh:バグレポート

gauche.nightプレゼン

gauche.nightでプレゼンしてきました。

• http://d.tir.jp/gauchenight/gauchegong/