2004/04/28 03:00:04 JST
- 今まで、適当一発インストールスクリプトを書く時は、Perl?で書いていたが、やっぱり、コレではよろしくない、と考え直し、見つけてきた↓のサイトを見つつ、/bin/shプログラミングを基礎からやり直す事に。
2004/04/25 23:24:15 JST
- この前に修理に出した家マシンは無事に修理されて戻ってきた（矢張り、biosだかcpuだかの故障だったらしい）が、その電源アダプタがサラネコフネズミに齧られて、使えなくなってしまっていた。
- 無難に新しい電源アダプタを買おうと思ったら、品切れらしい。困る。
- 自分で外科的手術を行うしかないのか…
2004/04/25 04:04:51 JST
2004/04/13 03:11:51 JST
- 下のドキュメントを読んでみたが、どうもよく分からない。
- socketからread()する場合、相手から切られると、read()は0を返すらしい
- socketからread()する場合、相手が音信不通になると、延々と待つらしい？？？
- socketにwrite()する場合、相手から切られると、SIGPIPEが起こるらしい
- socketにwrite()する場合、相手が音信不通になると、再送タイムアウトの規定秒まで待つらしい
- で、im_customのコードの方は、skklib.cのgetCandFromServer()を見たところ、
- read()が0または負値を返した時の対応は、多分大丈夫そうだ？（途中でskkserv側がsegvとかで死んだら、まずいような気はするが…‥）
- SIGPIPE対策のコードもあるようだ？（なんか役に立ってない気もするが…‥）
- とりあえず、変換途中でskkserv側が死ぬ事は無い、と考える事にする（ソレを考えると、自分にはどうしようもなさそう）。
- なので、skkservが落ちる／音信不通になるのは、通信していない間に起こる、という事になる（都合が良すぎるが）。
- この場合、getCandFromServer()の最初のread()で、0か負値が返ってきて、closeSKKserv()が実行されるので、skkservsockは-1になり、この回の変換は失敗するが、次回の変換時には問題なく再コネクトされると思う。
- なので、ココで行う改造は、
- openSKKserv()の最初で、既にskkservsockが-1以外なら、そのまま0を返して何も行わないようにする
- getCandFromServer()の中の、return NULL;している箇所の前で、ちゃんとcloseSKKserv()を実行するようにする（そうしないと、この後永遠にopenSKKserv()が行われない）
- となる。
- しかし、コレでは何故か、二回目の変換が出来なくなってしまった！
- と思ったら、単に、通信に問題ない場合でも間違ってcloseしてただけだった。コレなら大丈夫。
- …‥と思っていたら、長い間使っていると、前に候補になった一部が、次の変換時に漏れてきている…‥何でだ。
- 駄目だ…‥。
2004/04/13 01:51:24 JST
- im_custom、このままパッチとして投げようかと思ったが、あんまりな気がしたので、もうちょっと何とかできないか試して、駄目だったら投げる事にする。
2004/04/13 01:28:12 JST
- どうも、im_customに含まれるskk.cに、skk_dicloadという関数があり、それが呼ばれる度に、skklib.cにあるopenSKKservという関数が実行されるが、コレが毎回コネクションを張っているようなので、openSKKservを呼ぶ直前に（無害なのを確認してから）closeSkkservを実行するようにしてみた。
- コレで、確かに、コネクションは増えなくなったが、コレだと漢字変換毎にソケット通信開始切断＆プロセス起動の労働を行う事になり、頭が悪い。
- しかし、真面目に解決するなら、ちゃんとソケットが生きてるかどうかを確認してからソケットを再利用しなくてはならず、なかなか面倒そうだ。
- というか、誰もコレに気付かなかったのか…‥もしかして、im_custom+skkserv?で使ってる人誰も居ない？
2004/04/12 06:54:26 JST
- 試行錯誤しつつ、dbskkd-cdb安定版を入れて、高速にSKK変換が出来るようになった。
- しかし、vimから漢字変換を行う毎に、dbskkd-cdbのプロセスが一個ずつ増えていき、そのうち、tcpserverの最大プロセス数制限に引っかかって、どうしようもなくなってしまう。
- コレは一体どうすればいいのだ…‥。
- どうも、im_customの方で、socketをクローズしていないのが原因？
- しかしそもそも、skkserv?って、一回の通信が終わったら毎回socketをshutdownするモノなのか？こういうのはコネクション張りっぱなしにするような気も…‥。
2004/04/12 02:05:55 JST
- phttpdの開発はサボり気味。
- 今週末は、vim一発インストールスクリプトをいじっていて終わった。
- 何とかして、im_customでSKKが使えるようにしようといじってみたものの、実行するとsegvするvimしか出来上がらなかった。
- と思ったら、動いた。
2004/04/06 06:48:19 JST
2004/04/06 03:41:02 JST
- 家PCの停止→修理出しの為、家PCのCVSリポジトリが使えなくなってしまったので、このマシン上にリポジトリを移す事にした。
- 公開サーバにリポジトリを作る事になったのだから、折角だから、ViewCVSを入れた。
2004/04/05 06:26:51 JST
- とりあえず、phttpd/tcpd.scmに、簡単なスレッド化を行ってみた。
- 今のところ、スレッドプール等は全く行っていないので、パフォーマンスは悪いが、アクセスを並列に捌ける事は確認。
- 問題は、コレでservlet?を動かす場合、servlet?側もスレッド安全でなくてはならない、という点。
- servlet?追加時に、スレッド安全か否かのキーワードをつけて、スレッド安全ならそのまま実行、そうでなければmutexを使ってロックして並列に動く事がないようにする（つまり、非スレッドの時と同じように、後でアクセスした方は、先にアクセスした人が終わるまで、待たされる）、というのを考えていたが…‥。
- 可能なら、servlet?部分はCGI?スクリプトと互換の方が良いので、そういう事を考えずに済むような実装にしたいが…‥。
- よく考えると、こういう風にスレッドやforkを使ってしまうと、Apache?にmod_言語名で組み込んだインタープリタで実行するのと、大差が無くなるかもしれない…‥。
- そう考えると、やっぱり、CGI?ごとにプロセスを分けつつ、常駐させるという、FastCGIのアプローチが一番正しいようだ。
- 自分としては、CGI?以外でも使える、SpeedyCGI?のGauche?用があれば、そっちの方が良い気がするけど、自分はSpeedyCGI?のソースを見て諦め。
- とりあえず、どうするか。
- 最初に考えていた通り、servlet?毎にスレッド安全か否かのキーワードを設定させて、安全でないなら、直列動作で我慢する
- スレッドプールにして、スレッド生成時にservlet?も新しく作り直すようにする（Apache?+mod_言語名と全く同じアプローチになる）
- コレをするなら、最初からmod_gaucheでも作るべき。
- やっぱり、FastCGIが一番！という事で、FastCGIインターフェースを根性入れて作る
- 根性が要りそうだが、一番マシそう。とりあえず仕様書ちゃんと読む事。
- とりあえず、サクッと1を作ってから、3に移る方向にしよう。
2004/04/04 23:15:29 JST
2004/04/04 06:55:51 JST
2004/04/04 00:16:39 JST
- 家PCが突如、CPUかBIOSレベルの破損が起こったのか、完全に起動しなくなってしまった。
- とりあえず修理に出したが、作業中のデータが入ったまま修理に出してしまった。
- 必要なデータぐらいはHDDだけ取り出してサルベージしておくべきだったか。
- とりあえず、放置してあった旧マシンをまた使う事に。
- （あまり人には言えない、情けない理由により）会社から取り残されそうだ。
- コレを機に転職するというのもアリだとは思うが、他所の会社で、今の会社以上に良い環境で過ごせるか…‥となると、おそらくそんな会社は他に無いように思える（但し、給与面は除く。給与が上の会社はいくらでもあるだろうが…‥）。
- しかし、このままでは、どうしようもない状態になるのは目に見えている。何とかしなくてはならないが…‥。
- mod_fastcgiの日本語訳ページが403になっている。
- どうも、コレは、IBM?が販売しているweb serverに付属のマニュアルを自前で翻訳したものが、（当時はアクセス制限されていなかったので）偶然googleに流れてしまったもののような気がする。
- 現在はgoogleキャッシュからも無くなってしまった…‥。
- とりあえず、mod_fastcgiのページはこのままではまずいと思いつつ、どうするかは後で考えよう。
- もしかすると、ココから、「Japanese」を選択してダウンロードすると、中に含まれてるのかもしれない…‥。
最終更新 : 2004/05/03 16:54:17 JST