- 1 名前：somebodyさん mailto:sage [03/03/23 13:20 ID:???]
- Ｃ言語で書かれたＣＧＩってなかなかｲｲもの見つかりませんよね。
前Ｃでかかれた掲示板を見かけたんですけど、なんかタグ用の処理が行われていないらしくて、グロ画像やエロ画像なんて
貼りたい放題でしたよ・・。わたしなんて<xmp>タグを貼りかけましたよ・・・
それはどうでもｲｲとしてＫＥＮＴさんのＣＧＩみたいに高機能で手軽なＣＧＩのＣ言語版みたいなのがあったらなぁなんて思ったことありませんか？
このスレではそんなＣＧＩについて語って、ＣでＣＧＩの考えを普及していきたいです。
- 501 名前：nobodyさん mailto:sage [2009/03/31(火) 09:58:41 ID:???]
- >>500
高速化にこだわるなら、自分でアプリケーションサーバ書くのがいいのでは
Apache臭はするけど、libaprなんかを使えばOSポータブルなdl()とかスレッドとか
メモリプールとか基本データ構造とか入っててお得ですよ。
ま、それなりにデカいけどね。
- 502 名前：普及された人 [2009/03/31(火) 22:35:52 ID:Tx3EmaFc]
- この掲示板に出現する人は「Ｃ言語でＣＧＩ」をいかに、、、というのが目的ですし、
ＣＧＩ部分を作るだけでも創造を絶する時間がかかりますので、アプリケーションサーバから作り始めるのは大変です。
今は情報が出回っていますので、作るに無理なことはないとは思いますが、一人で仕事外の時間利用だけで考えると、私ですと５年以上はかかりそうです。
Ｗｅｂアプリ一つ作るのにそれは効率的ではありません。
それにlibaprは、別にＷｅｂアプリケーションが高速になるものでもありません。
遅くなる可能性はあるけれど、作るときに便利で楽になるＡＰＩだと思います。
Ｃ＋＋技術者でない純粋なＣ言語技術者は、あまり使わないＡＰＩだと思います。
使わざるを得ないＡＰＩ以外は、基本的に存在を知らなければすぐに自作してしまいますので。
「Ｃ言語が使える」ということは、別段便利なＡＰＩを使う必要がないということでもあります。
libaprでメモリプールしなくとも、必要な分だけスレッドを立てて、mallocやcallocだけでしっかりメモリ管理できるということでもあります。（時に失敗しますが）
おまけにlibaprのメモリプールは確保した領域をシステムに対して返却しないと記載されていましたので、逆にかなりコントロールしにくいＡＰＩな気もします。
それだけの手間（時間）をかけ、なおかつメモリ周りも適当な設計で良いのなら、普通にＣ言語でApache module型Ｗｅｂアプリケーションでも組んだ方が楽で高速で良いのではないでしょうか？
- 503 名前：nobodyさん mailto:sage [2009/04/01(水) 11:08:56 ID:???]
- 作る際の効率が問題なら、そもそもwebアプリでCは選択しちゃダメ。
5年って、アナタたぶん作ったことないから死ぬほど安全に見積もってるよね?
アプリケーションサーバって、そこまで作るの大変じゃないよ。やることは基本的に待つだけだし。
実際は余暇を二週間位でも最初のプロトタイプ位はできるんじゃ...
まぁ、既存の適当にかかれたCGIをスレッド対応にするのは骨がおれると思うけど。
libaprのメモリプールの返却云々については、apr_pool_create の第二引数参照。
作業とか、ループとかにサブプールを作って、必要なメモリはそこから確保して、
終わったらサブプールだけ開放するって感じで。
でも、確かにCGIじゃないのでもうやめます。
fastcgiもCGIじゃないのではって気するけど...
- 504 名前：nobodyさん mailto:sage [2009/04/02(木) 22:00:32 ID:???]
- C言語が向いてるのは、開発費が多少増えたとしても、
サーバ台数が抑えられるから、トータルコストが安くて済むような案件だね。
検索サーバとか、2chとか、アクセス数が多いサイトとかね。
- 505 名前：普及された人 [2009/04/04(土) 11:18:37 ID:JlRZ3FIj]
- >>503
はい、もちろん作ったことはありません。
それに、今までのところでは作る必要性も感じたことはありません。
私がＣ言語で既存のＡＰＩを利用せずにアプリケーションサーバを作ることを考えると、、、
FastCGIのようにアプリケーションサーバ（これはハードのことです）側にある複数のTCPクライアントCGIと通信をこなしながら処理を進めることや、
アプリケーション側に、どのようにどのくらいのメモリを与えるのかなどを考えると、
できるだけ汎用的なものにしようとすれば、TCP先で利用できるlibaprのようなＡＰＩを自分で作らないといけないし、、、
というような感じで、503さんとは少し論点がずれていたようです。
すみません。
だた、やっぱり基本的な考え方としてはFastCGIは
（Client → WebServer → FastCGI → CGI → FastCGI → WebServer → Client）
という形態ですので、アプリケーションサーバもFastCGIとほぼ同じで、
（Client → WebServer → AppServer → App → AppServer → WebServer → Client）
という形態になり、module型
（Client → WebServer(module型App) → Client）
の方が構成がかなり単純ですので、Ｃ言語で作ったCGIやAppの反応はかなり高速だと思います。
それに、やっぱりmodule型のＣ言語Appを一つ作る方が、
アプリケーションサーバとクライアントアプリケーションの両方を作るよりも遥かに楽だと思います。
それ以上に、FastCGIであれば、
FastCGI用Ｃ言語ＣＧＩを一つ作れば済みますので、労力は激減します。
ただ、やっぱりアプリケーションサーバはもとよりmocule型AppもCGIではありませんね。
あと、FastCGIはCGIプログラムをメモリ上に常駐させるのかさせないのかという違いで、基本的な仕組みはＣＧＩと同じと考えて良いと思います。
|
 |
