Fedora Core 5 に Gauche-fastcgi をインストール

手順。

http://www.fastcgi.com/#TheDevKit の http://www.fastcgi.com/dist/fcgi.tar.gz をダウンロード ./configure & make & make install
yum install mod_fcgid
Gauche-fastcgiをインストール。./configure & make & make install
httpd 再起動

Yum には mod_fastcgi はなくて、mod_fcgidだけがある。バイナリ互換性があってmod_fcgidのほうが高速だから、完全に置き換えられたのだろう。
mod_fcgid の設定ファイルは、/etc/httpd/conf.d/fcgid.conf
fcgi実行テストに、Gauche-fastcgiに同梱のtest.scmやsample.fcgiを使うとよい。

先日の継続サーバだと、知らぬ間にfastCGIの機能を安っぽく再実装していたようだ。
fastCGIに頼るように改造すれば、実用に耐える性能を手に入れることができると思う。

(追記)

fastCGIに頼るように書き直しをやっている。
そうしたら、Scheme:使いたい人のための継続入門の、"議論"で説明されている問題に、自分も直面した。

# なんで、kahuaでは継続ではなくて、部分継続を使う必要があるのでしょうか。継続で出来ないことなのか、それとも継続だとコストが高すぎるとか…一読しただけではわかりませんでした。
# なるほど指摘ありがとうございます。確かに説明してないですが、Kahuaの動作についても説明が必要ですねぇ。
Kahuaが生成するページAに含まれるリンクを突つくと、続きの計算が起動して次なるページBの生成を行いレスポンスを返します。この続きの計算はページAを生成するところで作ってます。つまり最初のリクエストーレスポンスの時に生成してます。
ということは、そのままだとこの続きの計算には「そのページAを返す時のソケットに対してレスポンスを返す」という計算が含まれてしまいます。ページBを返す時にはそのソケットは当然closeしてますから使えないわけですね。
それを回避するためにKahuaではKahuaプログラムのロジック内部と、毎回変化するクライアント-サーバ間の通信処理の部分とをreset/pcで分離しています。と、いうような話を出来るだけ分かりやすい形でまとめたいですね。まぁ面白い説明を思いついて気が向いたら後日書き加えることにします。

自分もこの問題に悩める日が来るとは、立派になったもんだ。

(以下は自分用メモ・・・説明になるかな)
先日の実装では、

常に同じところにページ生成の出力を吐く
吐かれたのがページAのリクエストの後なら、それをページAのレスポンスとして返す。吐かれたのがページBのリクエストの後なら、それをページBのレスポンスとして返す。

という風で、ページAのときでもページBのときでも決まったソケットに書き込むだけだったので、この問題は通り過ぎてしまっていた。
つまり

ページAのリクエストがきた -> /tmp/sockにサーバソケットを張る
常に同じところ /tmp/sock にページ生成の出力を吐く(クライアントソケット)
/tmp/sockへの書き込みをページAのレスポンスとして返す。
ページBのリクエストがきた -> /tmp/sockにサーバソケットを張る
常に同じところ /tmp/sock にページ生成の出力を吐く(クライアントソケット)
/tmp/sockへの書き込みをページBのレスポンスとして返す。

(さらに追記)
待てよ、サーバソケットを張るプロセスと、ページ生成するプロセスが別になってたから、継続の問題が生じなかったのか?