Ｃ言語のＣＧＩを語りつつ普及するスレ
■ このスレッドは過去ログ倉庫に格納されています
0001somebodyさん
03/03/23 13:20ID:???前Ｃでかかれた掲示板を見かけたんですけど、なんかタグ用の処理が行われていないらしくて、グロ画像やエロ画像なんて
貼りたい放題でしたよ・・。わたしなんて<xmp>タグを貼りかけましたよ・・・
それはどうでもｲｲとしてＫＥＮＴさんのＣＧＩみたいに高機能で手軽なＣＧＩのＣ言語版みたいなのがあったらなぁなんて思ったことありませんか？
このスレではそんなＣＧＩについて語って、ＣでＣＧＩの考えを普及していきたいです。
0396nobodyさん
04/09/08 15:18ID:???0397nobodyさん
04/09/08 23:56ID:???http://www.cgicc.org/
0398nobodyさん
04/11/08 18:55:43ID:???ttp://labo.cherrybooks.net/
0399nobodyさん
04/11/09 08:58:35ID:???0400nobodyさん
04/11/13 03:53:32ID:???0401nobodyさん
04/11/22 14:44:59ID:???0404nobodyさん
04/11/23 00:02:35ID:???仕事しろ！！
0405nobodyさん
04/12/14 17:59:04ID:upKknTNA宣伝の発見者の発見者の発見者を発見
0406402
04/12/14 23:08:12ID:???いいのかな…
0407nobodyさん
04/12/15 01:51:06ID:???0408nobodyさん
04/12/16 23:30:11ID:???Xサーバ
0409nobodyさん
04/12/17 01:56:16ID:???0410nobodyさん
04/12/27 15:06:04ID:2ZZk8VkA0411nobodyさん
04/12/27 17:17:19ID:???0413nobodyさん
04/12/31 11:29:26ID:???WINアプリがUNIXで動かないのは知ってるんですけど、なんとかならないですかね…
クロスコンパイラは都市伝説、PCはPen200、64MBのノートだからUNIX系OSはボツ…
0414nobodyさん
04/12/31 16:55:12ID:???GUIは苦しいかもしれないけどね。
0415nobodyさん
04/12/31 17:27:43ID:???0416nobodyさん
05/01/02 13:12:22ID:???藻前はPerlでも使っとけ
0417nobodyさん
05/01/02 15:32:49ID:???0418nobodyさん
05/01/02 22:40:11ID:???0419nobodyさん
05/01/02 23:07:18ID:???0421nobodyさん
05/01/20 11:30:37ID:???環境は自鯖仕様でWin2K+Apache2+VisualC++7
ＧＵＩならではの開発環境でデバッグが簡単になる方法ってあるんですかね？
自分はＶＣ６使ってたのでＶＣ7の.netによる恩恵がよるわかりません；；
実行ファイルをＣＧＩとして動かしてＶＣのデバッグトレース機能なんてできます？
用は実行ファイルの出力先にttp://hoge.com/abc.exeというのをＧＵＩでデバックとか・・
UNIXは知らんのですがWinsockを利用して細かいことしようとすると
画面出力で print "ENV= なんてしてるもので作業効率最悪。
どっちかとＶＣスレの質問かもしれませんがすまそ・・
あと上げてすんま孫
0422nobodyさん
05/01/20 12:35:15ID:???おにぎりの具で言うと何？
0424nobodyさん
05/01/21 01:48:24ID:???C++でCGIはアリかもね
0425nobodyさん
05/01/29 14:17:48ID:???0426nobodyさん
05/01/30 00:03:16ID:???じゃなくて、buffer overflowだと思う。
0427nobodyさん
05/01/30 11:45:02ID:???でも、Cでもバッファオーバーフロー対策なんて面倒という程大層なものじゃないが…
0428nobodyさん
05/01/30 18:51:23ID:???逆に、「C++だからバッファオーバーフローの心配はあまりない」
等と言う人の作ったものの方が、よっぽど危険だよ。
0429nobodyさん
2005/04/03(日) 17:49:44ID:???やっぱり慣れた言語が一番楽チンだね。組むのもデバッグも。
0430nobodyさん
2005/04/03(日) 22:52:40ID:???0431nobodyさん
2005/10/07(金) 11:12:03ID:???0432nobodyさん
2005/10/11(火) 02:40:04ID:???0433nobodyさん
2005/10/17(月) 16:43:58ID:???俺はとある企業で５年ほど、ＣのＣＧＩ開発をしていたよ。
某陸√系のサイトはほとんどがＣのＣＧＩで動いてるし。
相当無理なことやってるけど、相当無理ができることも事実だったりする。
0434nobodyさん
2005/10/25(火) 00:31:01ID:???0435nobodyさん
2005/11/03(木) 12:08:29ID:???ディレクトリ一覧をサブディレクトリまで
取得して、htmlタグを付与して出力するとか考えとるんですが。
perlだとおそいorz
0436nobodyさん
2005/11/03(木) 14:26:14ID:???キャッシュくらいしろ。
0438nobodyさん
2006/02/23(木) 13:35:40ID:oh1e7jqDかれこれ１０年ぐらいCでWebアプリの開発やってる。
いろんなライブラリを開発してたら、ソースが2MBにもなってしまった。
このライブラリだけでCGIに必要な機能はほぼ提供できるところまで来た。
PHPやPerlと変わらないレベルで開発できる。
このライブラリを公開したら面白いことになりそうだけど、
企業秘密満載だから、さすがに無理か。
0441nobodyさん
2006/05/06(土) 20:21:57ID:FWiKF0Gu>>企業秘密満載だから、さすがに無理か。
CPANとかある方がCからみたら異質なんだろうな。
一からライブラリ作るのは面倒だからAPRでもつかってみるかな。
0442nobodyさん
2006/06/04(日) 14:34:28ID:???そろそろ基本的な所だけでも共有しないか？
0443nobodyさん
2006/06/04(日) 16:22:13ID:???0444nobodyさん
2006/06/07(水) 05:48:07ID:???昔のヤツをひっくり返して見つかったらアップしてみる。
0445nobodyさん
2006/06/07(水) 14:16:56ID:???基本的なライブラリの共有と並行して、
どうすればC言語でcgiが書けるのかという基本の解説がいるね。
hello worldのC言語cgi版みたいなの。
0446nobodyさん
2006/06/08(木) 20:50:36ID:???だけで、
<HTML>
<BODY>
Hello World!
</BODY>
</HTML>
ぐらいは、生成してくれるとかさ。
0448nobodyさん
2006/06/09(金) 16:12:46ID:mYrnmPP60449nobodyさん
2006/06/10(土) 08:37:10ID:???stdio.hには無かった。
0450nobodyさん
2006/06/11(日) 02:28:25ID:???TCP/IPの通信部分から書かなきゃﾀﾞﾒかなぁ？
0452nobodyさん
2006/06/11(日) 09:10:11ID:???ドキュメントぐらい読んだら？
0453nobodyさん
2006/06/11(日) 10:43:01ID:???thx!!
0454nobodyさん
2006/06/18(日) 20:19:39ID:???You don't have permission to access /index.cgi on this server.
っていわれてうごかないんだ。
httpd.confに
Options ExecCGI
AddType application/x-httpd-cgi .cgi
って記述してるし、パーミッションも755になってるのにどうして？
0455nobodyさん
2006/06/19(月) 00:00:15ID:???SELinuxとかどうなってる？
使ってないの前提として、ﾊﾟｰﾐｯｼｮﾝてどこのﾊﾟｰﾐｯｼｮﾝだ？
ﾃﾞｨﾚｸﾄﾘの方はどうなってる？
所有権は？
迷ったら777試せ
0456454
2006/06/20(火) 11:17:11ID:???Windowsのxampp上では動くのに・・・
777もやってみたけどダメだった
所有権は777だから別に違っても大丈夫なはず
ディレクトリは見てなかったけど同ディレクトリ以下の
phpは走るし大丈夫なはずじゃ・・・あ
帰ったら試したいことが出来ました。
まだ解決してないけど>>455さんまりがとう('∀｀)
0457nobodyさん
2006/08/06(日) 17:59:11ID:???ぐぐったらウェブオブジェクト4.5とか出て来たけど、これはマカ専用？
0458nobodyさん
2006/10/20(金) 15:32:14ID:???使ってる企業は多いだろうけど、
目的の一つとしてソースをクライアントに見られずに済む
というのがあるだろうから、どこも非公開なんだと思う。
0460nobodyさん
2007/04/30(月) 03:27:37ID:???Cだと
たしかに作業量は多いね。
スクリプト系の方がいいのかな。
0461nobodyさん
2007/07/23(月) 21:41:06ID:b9YG4RnE最近、Cで書かれた通販システムを見かけたよ。
0462nobodyさん
2007/07/24(火) 09:29:08ID:???$body = preg_replace('/([0-9]+)/', $hoge_array[\\1], $body);
echo $body;
で「￥」が使えませんってエラーがでるけど、エラーをひょうじしなければ目的の結果は得られる……
どうやってエラーださないようにするか…
0463nobodyさん
2007/11/14(水) 03:29:16ID:???0464nobodyさん
2008/01/08(火) 20:51:35ID:JKoPEtVY0465nobodyさん
2008/01/11(金) 00:42:29ID:???int main()
{
printf("Content-Type: text/html\n\n");
printf("<HTML><BODY>\n");
printf("保守\n");
printf("</BODY></HTML>\n");
return 0;
}
0466nobodyさん
2008/01/28(月) 15:21:41ID:???0467nobodyさん
2008/03/05(水) 00:20:30ID:SOAastXQ無駄？
0468nobodyさん
2008/03/05(水) 03:04:37ID:???かなり大変だという覚悟があるならどうぞ。
自作ライブラリを既に持ってる人じゃないと、
一般的な用途ではメリットは少ないかも。
0469nobodyさん
2008/03/06(木) 01:30:58ID:???大変そうだけど
楽しそうだからやってみようかな
しかしCの人は優しい人が多い気がする
0470nobodyさん
2008/03/09(日) 17:09:46ID:???考えられね；
0471nobodyさん
2008/06/10(火) 14:33:36ID:???とりあえず出力なんだけど、printfとかのf系出力は、stdout
に出せばうまくいくね。でもwrite(fileno(stdout),...はダメみたいだな。
とりあえず今日まで勉強したまとめ。
標準系
content-typeとかのmime header出力\n\n
本文
return 0;
異常系
printf( "status: 番号\n\n");
本文
exit(0);
0472nobodyさん
2008/06/11(水) 20:03:02ID:???エラーの出し方。
printf( "status: 404....\n\n");
0473nobodyさん
2008/06/12(木) 07:23:28ID:???じゃー、私も一つ。
セグメンテーション違反などでCGIが落ちて、
どこで落ちてるか分からない時は、
デバッグ用の表示と fflush(stdout); をちょくちょく実行すると良い。
0474nobodyさん
2008/06/13(金) 16:10:07ID:???なるほどですね。
fflushall()ってもうないんでしたっけ？
・パース文字列の切り分け。これが簡単かも。
first_string = strtok(string,"=&");
second_string = strtok(NULL,"=&");
....
リターンがNULLまで、繰り返しするのが良いかも。
・デバッグ用マイクロ秒表示
make_datetime_string(date_and_time);
gettimeofday(&tv,NULL);
snprintf((char*)str, sizeof(replace_date_and_time), "\n%s.%06d[%d] ", date_and_time, (int)tv.tv_usec, getpid() );
結局mod_xsendfile使っちゃいましたが、sendfile apiって早そうですねー。
これならＣＧＩでもパフォーマンスあがるかも。
0475普及された人
2009/03/18(水) 02:24:13ID:moAFEnFyC -> apache module
FastCGI + C
CGI + C
SpeedyCGI + Perl
mod_perl
FastCGI + Perl
CGI + Perl
mod_python
mod_php
FastCGI + Python
CGI + Python
mod_ruby
FastCGI + Ruby
CGI + Ruby
特徴として言語自体の速度差が順位を決める
0476普及された人
2009/03/18(水) 02:25:24ID:moAFEnFyC -> apache module
FastCGI + C
SpeedyCGI + Perl
mod_perl
FastCGI + Perl
mod_python
mod_php
mod_ruby
FastCGI + Python
FastCGI + Ruby
CGI + Perl
CGI + C
CGI + Python
CGI + Ruby
特徴として、ノーマルなCGIは極端に遅く、Perlの洗練された完成度の高さが伺える
0477普及された人
2009/03/18(水) 02:25:58ID:moAFEnFyC -> apache module
FastCGI + C
SpeedyCGI + Perl
mod_perl
mod_php
FastCGI + Perl
mod_python
mod_ruby
FastCGI + Python
FastCGI + Ruby
CGI + Perl
CGI + Python
CGI + Ruby
CGI + C
特徴として、動作の前段階のメモリ上で動作可能な状態になるまでの速度差（レスポンスの良さ）が順位を決める
0478普及された人
2009/03/18(水) 02:26:35ID:moAFEnFyC -> apache module
FastCGI + C
SpeedyCGI + Perl
mod_php
mod_perl
mod_python
mod_ruby
FastCGI + Perl
FastCGI + Python
FastCGI + Ruby
CGI + Perl
CGI + Python
CGI + Ruby
CGI + C
特徴として、提供方法にかなり影響される
0479普及された人
2009/03/18(水) 02:27:14ID:moAFEnFyC -> apache module （何も手間なし）
mod_php （apacheに標準で付いていることが多い）
CGI + Perl （apacheの設定ファイル変更）
CGI + C （apacheの設定ファイル変更）
CGI + Python （Linuxインストールで標準で付いていることがある＆apache設定）
CGI + Ruby （自分でインストール＆apache設定）
mod_perl （自分でインストール＆apache設定＆モジュール起動）
mod_python （自分でインストール＆apache設定＆モジュール起動）
mod_ruby （自分でインストール＆apache設定＆モジュール起動）
SpeedyCGI + Perl （自分でインストール＆apache設定＆モジュール起動）
FastCGI + Perl （自分でインストール＆apache設定＆モジュール起動＆コード宣言付加）
FastCGI + Python （自分でインストール＆apache設定＆モジュール起動＆コード宣言付加）
FastCGI + Ruby （自分でインストール＆apache設定＆モジュール起動＆コード宣言付加）
FastCGI + C （自分でインストール＆apache設定＆モジュール起動＆コード変更）
0480普及された人
2009/03/18(水) 02:28:00ID:moAFEnFymod_php （何も考えずHTML組み込みからすぐに始められる）
mod_ruby （Rubyを知っていれば、すぐに始められる）
CGI + Ruby （パーミッションとか知らないといけない）
FastCGI + Ruby （宣言付加しないといけない）
mod_python （Pythonを知っていれば、すぐに始められる）
CGI + Python （パーミッションとか知らないといけない）
FastCGI + Python （ド宣言付加しないといけない）
CGI + Perl （パーミッションとか知らないといけない）
SpeedyCGI + Perl （宣言付加しないといけない）
FastCGI + Perl （宣言付加しないといけない）
mod_perl （Perlを知っていても制約が多い）
CGI + C （面倒）
FastCGI + C （逐次動作可能プログラムにしないといけない）
C -> apache module （モジュール化の手間がかかる）
0481普及された人
2009/03/18(水) 02:29:05ID:moAFEnFy速度やサーバ負荷の観点から、ノーマルなCGIも極力避けたい。
性能第一、開発効率第二で考えた場合は、 FastCGI + C が良いが、開発効率を考えると SpeedyCGI + Perl も捨てがたい。
開発効率第一、性能第二、セキュリティはあまり考えない場合は、 mod_php もあり。
開発効率も良く、楽しむなら、 FastCGI + Python 、 FastCGI + Ruby で決まり。（私は FastCGI + C で楽しめますが）
ということで、
１、性能オタクの人にお勧め FastCGI + C
２、C言語しか知らない人にお勧め FastCGI + C
３、C言語が面倒でなかったり、面倒なことが嫌いではない人にお勧め FastCGI + C
４、C言語の達人にお勧め FastCGI + C
５、セキュリティを気にしながら質の高いサイト構築をしたい人にお勧め FastCGI + C
６、１００％完璧なセキュアプログラムを作れる人にお勧め C -> apache module
７、組み込み系好きの人にお勧め C -> apache module
８、チャレンジャーにお勧め C -> apache module
なのです。
あ、６〜８はmoduleだからCGIじゃないか。。。
私はURLデコードもエレメント抽出も全て自分でコードを書きました。
一つ一つの動作が理解できるのでC言語でのCGI作りはめちゃめちゃ面白かったです。
皆さん是非CでCGI（と言っても私のお勧めは FastCGI + C ですが）をしていきましょう！
なお、上記ランキングは勝手な私見ですので、当てにはなりませんので、ご了承ください。
あ、Java忘れてました。
0482nobodyさん
2009/03/18(水) 08:07:29ID:???0483普及された人
2009/03/18(水) 14:10:55ID:XMWgki/Qメモリと同等レベルの速度がでるようになれば、
ノーマルCGIもありだと思います。
現在でもRAM Disk化すればそれは実現できます。
特にCPU負荷の大きい処理ではノーマルCGIでも
C言語の選択は効果的です。
それでも、毎回ストレージにアクセスして、
プログラムを読み込み、プロセスを生成し、
実行後プロセスを破棄するノーマルCGIよりも、
プロセス生成済みの状態で、メモリに常駐して、
逐次再利用可能状態でプロセスの破棄が必要の
ないFastCGIの方が相当レスポンスが良いし、
ストレージに全くアクセスせずに動作するし、
プロセス生成や破棄のCPU資源を必要としないので
色々な意味でサーバ負荷も激減するので、
より良い選択肢だと思います。
0484普及された人
2009/03/18(水) 14:11:37ID:XMWgki/Q（日本のサイトでは情報が全くといっていい
ほどないので私は苦労しましたが、手順自体
は簡単です）にできるチューニングですので、
MyServerを持っていて、C言語でCGIを作って
いる人はやるべきだと思います。
PerlならFastCGIよりSpeedyCGIの方がより良い
選択肢だと思いますし、激重のRubyの場合は
FastCGIは必須と言ってもいいでしょう。
moduleタイプはWebServer（apacheなどの
プログラムの方のことです）内部で動作させる
ので、より高速ですが、プログラムのバグが
WebServer全体に影響しますので、危険度を考え
れば、選択肢からはずした方が無難に思えます。
CGIタイプの方が間違いなく絶対に安全です。
0485普及された人
2009/03/18(水) 14:14:04ID:XMWgki/Qサーバサイドプログラミングの中で最も高速
かつ安全な、まさに頂点に立つ方式だと考えます。
もちろん今の時代でC言語が使えるということは、
バッファオーバーフローの回避やコード部分に
おけるアルゴリズムの最適化などができることが
最低限の必要条件だと思いますが。
そうでなければ、高速かつ安全とは言えませんので。
0486普及された人
2009/03/18(水) 14:18:12ID:XMWgki/Q0487nobodyさん
2009/03/18(水) 20:57:18ID:???0488nobodyさん
2009/03/20(金) 05:46:26ID:???メモリ使用量や実効速度が速いというのは変。
あとプロセスを起動するたびに毎回HDDにアクセスとかありえない。
キャッシュに残ってるよ。
起動したら１行printして終わるだけのプログラムを、
CとPerlとbashスクリプトで作って、それぞれ起動してみたけど、
やはりPerlの方が時間がかかる。
$ time ./test.app
real 0m0.001s
user 0m0.000s
sys 0m0.000s
$ time ./test.pl
real 0m0.002s
user 0m0.000s
sys 0m0.001s
$ time ./test.sh
real 0m0.001s
user 0m0.000s
sys 0m0.001s
0489nobodyさん
2009/03/20(金) 05:50:52ID:???そのCGIでtimeを測ってみても、↓の通り。
ソースコードで2.2MB、バイナリで350KBとかなり大物だけど、
それでもphpの実行バイナリ3Mとかと比べれば、軽いもんだね。
real 0m0.001s
user 0m0.001s
sys 0m0.000s
0490普及された人
2009/03/21(土) 12:48:40ID:yqEMcysT>CGI + C より CGI + Perl / Python / Ruby の方がメモリ使用量や実効速度が速いというのは変。
その通りでした。
間違えて記載してしまいました。
実際は少なくとも CGI + Perl よりも全て上にランキングされます。
FastCGI + ? に関しては状況によるかと思いますが。
>あとプロセスを起動するたびに毎回HDDにアクセスとかありえない。
>キャッシュに残ってるよ。
OSやハードディスクの行うキャッシュに関しては、他の要因で追い出されることが考えられますので、無視して記載しました。
それまで入れてしまうと、CGI自体の動作やFastCGI自体の動作やSpeedyCGI自体の動作やmodule型自体の動作の説明ではなくなってしまいますので。
CGI→エグゼキュートやインタプリタ＋スクリプトをストレージから読み込み実行
FastCGI→エグゼキュートやインタプリタ＋スクリプトをプロセスとしてメモリに常駐させそれを実行
SpeedyCGI→バイトコードをプロセスとしてメモリに常駐させそれを実行
module型→エグゼキュートやインタプリタをWebServerのModuleとして組み込みメモリに常駐させ、スクリプトはストレージから読み込み実行
という風にそれぞれの機能を説明したかったのでそう記載しました。
0491nobodyさん
2009/03/21(土) 15:47:08ID:???なるほど。
私のCGIもapache moduleかFastCGIにしたいんだけど、
CGI専用にAPI開発したから、メモリ解放が手抜きすぎて無理だｗ
0492普及された人
2009/03/21(土) 21:30:03ID:yqEMcysTでも、それだけの実力者なら、時間は多少かかるものの簡単にできるのではと思います。
私の場合は、最初はプログラムの中でFastCGI仕様にしようとやっていたのですが修正が多すぎたので、main関数自体を別関数に変えてFastCGI仕様にしたらかなり楽に解決できました。
外部変数さえなければ、この技（というほどのものでもないですが）は有効だと思います。
apache moduleとして組み込むのは、一人で開発してますので、チェック機構（自分自身）に信頼がおけないのでやらないことにしました。
Ｃ言語で作る場合、FastCGIとmodule型は速度的にそれほど大差がない（処理速度は同じで、結果をWebServerプロセスに渡す渡し方の差しかない）ので、どちらでも良いのでしたらFastCGIを私はお勧めします。
スクリプト言語で組むなら、圧倒的にSpeedyCGIが抜きん出て、FastCGIのスクリプトを常駐させるアドバンテージとmodule型のスレッド通信のアドバンテージが相殺してあまり大差ないようですが。
いずれにしても、Ｃ言語でＣＧＩが組めるのは（その根性があることこそが）大きなアドバンテージですので、お互いに頑張って良いものを作って普及させましょう！
0493nobodyさん
2009/03/22(日) 04:05:46ID:???> 相当大きなものなのでしょうか？
そだねー。
フォーム受け取り、XML-RPC、クッキー、
MD5、各種暗号復元化、base64、文字コード変換、絵文字、
いろいろなDBに対応したモデル、それのコントローラ、HTML埋込ビュー、
画像処理、セッション、ユーザ処理、画像認証、各種ユーティリティとかあるよ。
いくつかはUNIXでメジャーなAPIの呼び出しで実現してる。
もう設計からして、メモリ解放を前提としてないから、
もしやるとしたら、参照カウンタ＋ガベージコレクションの実装かな。
0494普及された人
2009/03/22(日) 17:50:13ID:uHOLJ9Dp素晴らしい財産の数々、驚きました。
確かに、これら全てを改変するというのは重労働ですね。
でも、それ以前にこれらを作ってきたことが、とてつもない重労働です。
私には、高い品質で世に（無償）提供したいものがありますので、いくつかのものは作りましたが、かなり多くのそういった財産を作っていかないといけません。
今まで、492さんがやってこられた重労働です。
それをやることに比べたら、一つ一つのコードのメモリ開放型への変更は、基本的にはオブジェクト指向でないＣ言語で、これまでやってきた492さんにとっては、克服できるのではないでしょうか。
module型やFastCGI用にするとなると、確かにそれ専用で設計した方が良いものが結構ありますので、この際せっかくですので、一括でドン！ではなく、後世に残る財産と思ってチマチマやってみてはいかがでしょうか？
これだけできる人ならきっとすぐにできると思います。
私も始めた当初は、スクリプト言語で同じものを作る１００倍以上の時間がかかっていましたが、今では２倍程度の時間しかかかりません。
せっかくのＣ言語でＣＧＩですので、より高い品質のものを期待しています。
・・・というか、492さんは全盛期のYahoo!にでも勤めてた（る？）のでしょうか？？？
0495nobodyさん
2009/03/23(月) 02:32:56ID:???私もこのAPIをもうちょい作り込んで、オープンソースででも公開したいんですが、
すでにいくつかの大手サイトで使っちゃってるので、
ソース公開してセキュリティホールが見つかったら怖いので、公開に踏み切れないｗ
> ・・・というか、492さんは全盛期のYahoo!にでも勤めてた（る？）のでしょうか？？？
ずっとフリーで活動してますよ。
でも最近は仕事が激減して、暇を持てあまし中 orz
0496nobodyさん
2009/03/23(月) 17:53:50ID:???理解できなくて移行をためらっているので、もし良ければ質問に答えてもらえるとありがたいです。
CGIをFastCGIにすると、プロセスがメモリに常駐してFCGI_Acceptのループでリクエスト待ちになる
みたいだけど、このとき複数のリクエストが同時に来たらどう対応されるの？
1. 一つのFastCGIのプロセスで順番に処理される
2. FastCGIのプロセスが新たに立ち上げられて、並行して処理される
"1" ならアップローダーみたいな処理に時間のかかるものにはFastCGIは向かないって認識でいいのかな？
（そもそも処理に時間がかかるなら起動コストの影響は少ないからノーマルCGIでいいのだろうけど）
"2" ならせっかく常駐するのだから、データの内容をメモリにキャッシュして高速化しようとかすると、
複数立ち上げられたときにメモリを大量に消費しちゃうのでやらないほうがいいのかな？
試してみればいいのだろうけど、FastCGIに興味はあるけど今のところはC言語CGIだけでもCPU負荷で
困ることはなかったので、環境構築するところまでは踏み切れずにいました(^^;
■ このスレッドは過去ログ倉庫に格納されています