Ｃ言語のＣＧＩを語りつつ普及するスレ
■ このスレッドは過去ログ倉庫に格納されています
0001somebodyさん
03/03/23 13:20ID:???前Ｃでかかれた掲示板を見かけたんですけど、なんかタグ用の処理が行われていないらしくて、グロ画像やエロ画像なんて
貼りたい放題でしたよ・・。わたしなんて<xmp>タグを貼りかけましたよ・・・
それはどうでもｲｲとしてＫＥＮＴさんのＣＧＩみたいに高機能で手軽なＣＧＩのＣ言語版みたいなのがあったらなぁなんて思ったことありませんか？
このスレではそんなＣＧＩについて語って、ＣでＣＧＩの考えを普及していきたいです。
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負荷で
困ることはなかったので、環境構築するところまでは踏み切れずにいました(^^;
0497nobodyさん
2009/03/25(水) 15:31:05ID:???なければ立ち上げるってだけ。
プロセスの生死自体は親が握っていて、同じインスタンスが同時に動くことがある
ってのを覚えておけば、データをメモリにおいて使いまわすことは可能。
っていうかLinuxとかのOS標準のdevパッケージを使うなら、Hello, worldなcgi自体は
環境構築含めて15分もあれば出来るので、めんどくさがらず試せばよろしい。
0498普及された人
2009/03/26(木) 22:41:51ID:4YbFu+ijこれだけの実力者が暇を持て余しているとは、世の中狂っています。
これだけの実力者なら凡人がRubyで3000ステップの素晴らしいプログラムを作る時間で、10000ステップの同等の機能の素晴らしいプログラムを作るでしょうに。
早く、プログラマのフリーエージェント的な制度が確率すると良いと思います。
力のある人が、それなりの報酬を得られることは必要です。
それがなければ、努力もせずダラダラとIT業界に執着する人が増えるばかりです。
オープンソース化できるのなら是非してもらいたいです！
それこそＣ言語でＣＧＩの普及になります。
> ソース公開してセキュリティホールが見つかったら怖いので、公開に踏み切れないｗ
だからこそオープンソースで良いのではないでしょうか？
一人の力には限界がある。
だからこそ、みんなの目で見てもし穴があるのなら、みんなで埋めていけば良いのだと思います。
完璧なものを公開して、威張るためのものがオープンソースではないと思います。
0499普及された人
2009/03/26(木) 22:43:44ID:4YbFu+ij私が自分自身で言っていることと相反するようですが、495さんもおっしゃってたように、実動作では通常のＣＧＩでも、キャッシュ化されますのでかなり高速です。
Ｃ言語の場合、処理自体が早いですから。
理論的に考えるとかなりの差ですが、実動作で考えると多くの場合FastCGIと通常のCGIの差は、「プロセスの生成」と「プロセスの廃棄」の時間になるかと思われます。
それと、昨日事情があって、Rubyの全コード見てみましたが、、、
素晴らしいプログラムで、感想は色々ありますが、とにかく長いですねぇ。。。
Ｃ言語のソースだけで、30ファイルくらいありますから、普通に流しで見るだけで４時間くらいかかってしまいました。
あのプログラムがインタプリタとして、スクリプトを読み込み処理することを考えると、遅いのが良く理解できます。
どれだけでかいＷｅｂアプリケーションをＣ言語で作ったとしても、あれほどでかくはなり難いので、間違いなくＣ言語で作ったＷｅｂアプリケーションは高速でメモリも食いません。
そう考えると、Ｃ言語のＣＧＩだけで困っていないのなら、それでも良いかと思います。
ただ、多少の苦労で、無料で簡単に高速化できることは間違いないですし、多少のスキルアップにもなるかとも思いますので、是非一歩を踏み出して欲しいと思います。
RailsもRackをデフォルトとして一生懸命「単純化」や「高速化」を目指しています。
それよりも高いレベルのものが手の届くところにあるのですから、掴んじゃいましょう！
「手間がかかっても、面倒くさがらず、納得のいくアルゴリズムを完成させる」
「少しでも可能性があるのなら、より素晴らしいものを作るために努力を惜しまない」
それがＣ言語技術者だと思います。
色々相性など言われていますが、少なくとも私はApache & mod_fastcgiでとても安定動作しています。
やってみてダメなら戻せば良いのではないでしょうか？
で、仕組みに関して私のわかるレベルで、解説ページを作ってみました。
急いで作ったので、おかしいかもしれません。
間違いがあれば、ご指摘ください。
ttp://www.dreamhope.net/soliloquies/webtec/
0500nobodyさん
2009/03/27(金) 13:34:24ID:???ありがとうございます。おかげでFastCGIを使ったときのイメージが理解できました。
FastCGIは興味があったけど、試してみるのが面倒というよりは、試してみるとのめり込んでしまいそうで
目の前にあるやらないといけないことをおろそかにできない状況だったので試せなかったのです。
元々はアセンブラでプログラムを組むのが趣味だったような人間ですので、手間よりも高速化が好きですから
今後は少しずつFastCGIも利用していきたいと思います。
0501nobodyさん
2009/03/31(火) 09:58:41ID:???高速化にこだわるなら、自分でアプリケーションサーバ書くのがいいのでは
Apache臭はするけど、libaprなんかを使えばOSポータブルなdl()とかスレッドとか
メモリプールとか基本データ構造とか入っててお得ですよ。
ま、それなりにデカいけどね。
0502普及された人
2009/03/31(火) 22:35:52ID:Tx3EmaFcＣＧＩ部分を作るだけでも創造を絶する時間がかかりますので、アプリケーションサーバから作り始めるのは大変です。
今は情報が出回っていますので、作るに無理なことはないとは思いますが、一人で仕事外の時間利用だけで考えると、私ですと５年以上はかかりそうです。
Ｗｅｂアプリ一つ作るのにそれは効率的ではありません。
それにlibaprは、別にＷｅｂアプリケーションが高速になるものでもありません。
遅くなる可能性はあるけれど、作るときに便利で楽になるＡＰＩだと思います。
Ｃ＋＋技術者でない純粋なＣ言語技術者は、あまり使わないＡＰＩだと思います。
使わざるを得ないＡＰＩ以外は、基本的に存在を知らなければすぐに自作してしまいますので。
「Ｃ言語が使える」ということは、別段便利なＡＰＩを使う必要がないということでもあります。
libaprでメモリプールしなくとも、必要な分だけスレッドを立てて、mallocやcallocだけでしっかりメモリ管理できるということでもあります。（時に失敗しますが）
おまけにlibaprのメモリプールは確保した領域をシステムに対して返却しないと記載されていましたので、逆にかなりコントロールしにくいＡＰＩな気もします。
それだけの手間（時間）をかけ、なおかつメモリ周りも適当な設計で良いのなら、普通にＣ言語でApache module型Ｗｅｂアプリケーションでも組んだ方が楽で高速で良いのではないでしょうか？
0503nobodyさん
2009/04/01(水) 11:08:56ID:???5年って、アナタたぶん作ったことないから死ぬほど安全に見積もってるよね?
アプリケーションサーバって、そこまで作るの大変じゃないよ。やることは基本的に待つだけだし。
実際は余暇を二週間位でも最初のプロトタイプ位はできるんじゃ...
まぁ、既存の適当にかかれたCGIをスレッド対応にするのは骨がおれると思うけど。
libaprのメモリプールの返却云々については、apr_pool_create の第二引数参照。
作業とか、ループとかにサブプールを作って、必要なメモリはそこから確保して、
終わったらサブプールだけ開放するって感じで。
でも、確かにCGIじゃないのでもうやめます。
fastcgiもCGIじゃないのではって気するけど...
0504nobodyさん
2009/04/02(木) 22:00:32ID:???サーバ台数が抑えられるから、トータルコストが安くて済むような案件だね。
検索サーバとか、2chとか、アクセス数が多いサイトとかね。
0505普及された人
2009/04/04(土) 11:18:37ID:JlRZ3FIjはい、もちろん作ったことはありません。
それに、今までのところでは作る必要性も感じたことはありません。
私がＣ言語で既存のＡＰＩを利用せずにアプリケーションサーバを作ることを考えると、、、
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プログラムをメモリ上に常駐させるのかさせないのかという違いで、基本的な仕組みはＣＧＩと同じと考えて良いと思います。
0506nobodyさん
2009/06/05(金) 15:35:04ID:???のtextをtestと打って
2時間もプログラム自体が丸ごと落ちてくる現象に悩まされた
鬱だ
0507nobodyさん
2009/06/08(月) 22:46:07ID:???0508nobodyさん
2009/08/20(木) 02:18:22ID:???ダウンロードサーバには結構いいです。
公開しよと思うんですがいいところはありますか？
ＣＧＩというか、必要な所にソース書けばいくらでも
Ｃで拡張できます。
0509nobodyさん
2010/01/23(土) 12:51:26ID:???DoS攻撃かと思うほどのアクセスかけてやってもC先生は華麗にさばく
しかしまあ、スピードは慣れる
開発はPerlなら普通にある、デコードとか自分でひいこら書くのがめんどくさい
特にヒアドキュメントと連想記憶は欲しかったな
連想記憶はなんとかつくったけど ヒアドキュメントないからPrintfの嵐になる
C++でもいいのかも知れんが なんか道具の大掛かりさに比べてやってる事が間違ってる感じは否めない
それにCのほうがやっぱ早いしメモリも少しで良い
費用対効果で言うとCに比べてちょっとだけ苦労が減る分の物が手に入るとは思えない
0510nobodyさん
2010/01/23(土) 13:03:42ID:???そんなにperlが好きか
0511nobodyさん
2010/01/23(土) 17:41:22ID:???printfはもってのほか
普通にテンプレートエンジン使うか作るかしろや
ClearSilverとかあるだろ
0512nobodyさん
2010/01/23(土) 18:23:11ID:???Cから利用するなら汎用的なテンプレートエンジン使うより、自分のサイトに特化したページ出力するのみなら
自分で書いた短いコードのほうが可読性も高いしバイナリも小さいし、ぜんぜん速いよ(仕組みはだいぶ真似さしてもらったけど)
もちろん規模にもよるから
いちいちそんなコード書いてられないほどサイトが巨大、複雑化したら考えるけど
ヒアドキュメントはつかってないよCだから
マクロでそれっぽいことはしてるけど
0513nobodyさん
2010/01/23(土) 18:46:19ID:???>printfはもってのほか
>テンプレートエンジン使うか作るかしろ
上でも言ったようにテンプレートエンジン的なものは作ってるけど
でもprintfなしでどうしろと？ ぜんぶ一度メモリに入れてputs ?
そして使うなという理由は何？
ClearSilverだってprintfとかsprintfとか中できっと使われてると思うんだが
0514nobodyさん
2010/05/13(木) 15:17:05ID:Xm7v6t580515C言語でオラクル
2010/12/02(木) 16:28:59ID:eppaTORw３０日間は只なので試してみたら、さくさく動いた。
アパッチの設定も簡単だった。でも、説明がアバウトすぎるかな！
ろじねこさーばーという名前だった。
今までの苦労は、一体なんだったんだろう。
0516nobodyさん
2010/12/07(火) 02:17:17ID:4Sc5N9W90517nobodyさん
2011/01/16(日) 06:23:38ID:???0518nobodyさん
2011/01/17(月) 15:11:49ID:???PHPだとなんかモジュールがどうとかでCGIより負荷が少ないって聞いたんだけど
0519nobodyさん
2011/01/17(月) 16:22:26ID:???0520nobodyさん
2011/03/10(木) 07:17:46.39ID:hTkK9cNu****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
http://sky.geocities.jp/ttl_ttl_ttl_pic/
NASMでC言語を作る NASMで高度な設計書類とNASMの簡単な利用方法のサイトです
C言語のHEADの作り方 DLLファイルの作り方が書いてあります
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
****************************************************************
0521戦士カンガイバー ◆DMLinuxPbA
2011/04/30(土) 16:34:39.05ID:???0522CWLK2010
2011/07/05(火) 20:51:09.02ID:uC4ca/AsCGIで操作します。コード生成機能をいれたのでゴタゴタしてますがα版になりました。
使い方少々難しいですがいかがですか？
http://sourceforge.jp/projects/cwlk/
0523nobodyさん
2011/07/05(火) 21:23:31.64ID:???0524nobodyさん
2011/10/24(月) 11:24:39.84ID:???徐々にWEB フレームワークになっていき・・・
可搬性を考慮してインタプリタにしていき・・・
結果スクリプト言語に至る・・・と。
まさに車輪の開発。アホらし
0525nobodyさん
2011/12/04(日) 14:03:48.36ID:uP5znhXd例えばcgiのようにアクセスごとにphpやcなどが起動する仕組みから
いったん起動させておいて常駐させ、
リクエストごとに処理をさせる為の具体的なphp,c側の実装方法について
詳しい方いらっしゃいますか？
0526nobodyさん
2011/12/04(日) 16:46:29.57ID:uP5znhXdttp://www.dreamhope.net/soliloquies/webtec/
ここの住人だったのか。すげー面白い記事でした。
0527当日商品を出しました
2011/12/06(火) 00:55:02.17ID:GHsKaAnV4-7日到着します。
よろしくお願いします
店長：吉田 杏子
0870
http://xua.me/dSB
0528nobodyさん
2012/12/09(日) 01:11:22.01ID:???作り込んでるけど、HTTPプロトコルが面倒臭過ぎて嫌になる。
0529nobodyさん
2012/12/24(月) 20:37:21.15ID:C9oBUMu+
■ このスレッドは過去ログ倉庫に格納されています