2002年02月18日(月) 月曜日
■ 会社
- 7:10 おはよう。全然眠れんかった。今日は早く帰ろ。
- 9:40 バグ直ったかも！LstSetDrawFunction()がちゃんとよばれてなかったのだ。きっと。きっと。この関数要チェックや。
- 10:40 開発にメリハリをつけねば。これからメモ入力画面に縦スクロールバーを付ける。こんなもんは11:00までには終わる。
- 10:55 スクロールバーはあっさり付いた。わはははは。
- 18:40 検索の実装に取り掛かるがどうしたらいいのかわからない。あたふたしてしまうぞ。で、Kの監視とテープ交換をせねばならないことに気付いた。はぁ。
- 20:30 結局こんな遅いじゃん。
■ テレビ／本
- なんもない。
2003年02月18日(火)
■ 会社
- （11:50）出社。午前中休暇。今日も田園都市線車両故障だったようだ。
- （13:30〜15:00）兒玉相澤に引継ぎ。疲れた。うまく説明できない。
- （夕方）事務所対応考える。やはり色々面倒。忙しい。
- （19:10〜20:00）食事。
- SQL ServerのDBがシングルユーザモードになっていたので復旧。多分巨大なバックアップファイルを放っておいたためディスク領域が足りなくなったのが原因だ。領域を空け復旧。
- 社長から時間管理の重要性を訴えるメイルが来たけど、結果がタイムカード導入になる理由が分からない。時間管理が重要なのは当たり前ですね。ここに書いても仕方ないが辞める人間が社長とやりあっても仕方ないし。
- （21:00）メイルを書いたりしてたら遅くなった。帰ります。
■ [java][web] Jetspeed日本語表示計画
Jetspeedの情報が少しある。こちらの日記より。Jetspeedはまだいまいちなのかなあ。
■ [java][web] PageMixer
「PageMixer は、ウェブコンピューティングでのサーバ側 プレゼンテーションにおける JSP および XMLC の代替手段の一つです。」だそうです。What's New About Javaより。
■ 川本裕子さん
そういえば、社長お気に入りの川本裕子さんは梅田望夫さんのblogで賞賛されていました。賢い方なのですね。
2004年02月18日(水)
■ [life] 環境構築
コーディングは一時中断して、今日は丸一日をテスト用の環境構築に費やした。
PC3台にNetBSDをインストール、新宿へ行きNIC6枚とハブ2台ケーブル10本を購入、NIC10枚を取り付けPC5台を移動しケーブルで繋ぐ、各ネットワークで通信ができるように色々設定をして一日終了。ハブとケーブルは種類が色々あったのでどれを買うか悩み無駄な時間を使ってしまった。そんなのどれでもいいのに決められないのだ。
pingが通らなくて酔ったF先生のお世話になった。FreeBSDにてごにょごにょいじられたカーネルが動いていたのが原因だったようだ。解決してくれてありがとう。
これでおれの机の上はPCだらけになった。騒音がちと気になる。今日はアプリケーションのインストールまで進めなかったので、明日も環境構築の続きをやるからコーディングできそうにない。これでは終わらんよ…。
■ やること
- 決算
納品請求契約
2005年02月18日(金)
- 最近毎日寒いですね。
- だいぶプログラム安定した。一安心。もう半分の方はどうなるのかな。
■ [java] 「Eclipse RCP によるリッチクライアント開発入門」 （豆蔵）
WEB+DB PRESS に載っていた記事が読めるようになっていたのでメモ。まあRCPを使うことはないと思うけど。オレンジニュースより。
■ [javascript] 「ECMAScriptチュートリアル」 （AKAMA Shun-ichi's website）
よさそうなのでメモ。オレンジニュースより。
■ [link] 「Yahoo!保険」
てのがあるのね。なんとなくメモ。
Yahoo!保険では、さまざまなタイプの保険商品をインターネットで比べて選べます。インターネットでオンライン契約や簡単資料請求ができ、しかも、人手を介さないので煩わしい交渉や大切な時間を取られることもありません。
■ [link][service] 保証人代行サービス
今日の産経新聞に、部屋を借りる際の保証人になってくれるサービスが紹介されていたのでメモ。
- JID-トリオ （日本賃貸保証）
賃貸保証システム『JID-トリオ』は、賃貸住宅に関わる従来型の個人連帯保証を、法人としてお引受けするシステムです。
- パーフェクト保証制度 （日本セーフティー）
家を借りるとき、日本セーフティが保証人になります。
家賃1ヵ月分の25〜30%払うと2年間保証人になってくれるみたい。
■ [unix] 「Mini Kernel Dump」
日経Linux 3月号にちらりと紹介されていたツールをなんとなくメモ。LKCDと同種で、Linuxのクラッシュダンプをとるもの。
VAリナックスとNTTデータによるプレスリリースに少し説明があった。
既にLinuxシステムでは、LKCD、netdump、diskdump といったクラッシュダンプ機能が存在しますが、 これらはダンプの出力をそのLinuxシステムで使用されている既存のデバイスドライバを使用するなど、 Linux カーネルがもはや信用できないという障害発生時においてLinuxカーネルが正常に動いていることを前提として設計されているという大きな矛盾を抱えています。
ミニカーネルダンプでは、これらの問題を解決するために、システム障害時に障害が起きているLinuxカーネルとは別の小さなダンプ取得専用のLinuxカーネルを起動してダンプを行うという、既存のLinuxカーネルにまったく依存せずダンプを採取する手法を用いています。
また、ミニカーネルダンプでは、既存のLinuxカーネルに対する修正が非常に少ないため、ダンプ機能の組み込みのためのハードルは低く、またデバイスドライバの修正が必要ないためどのようなハードウエア構成のシステムでも動作するという特徴を持ちます。
■ やること
- リンク元のスリム化
- tDiaryバージョンアップ
- FSWikiバージョンアップ
- オーブンレンジ用べんり棚
- 確定申告書作成
- ブラウンの安い電動歯ブラシ買う
2007年02月18日(日)
■ [net] select()を通過したのにrecvfrom()でブロック
Fedora Core 5でUDPを扱っていて、select()は通過したのにその後のrecvfrom()でブロックしてしまいプログラムが止まってしまうという現象に遭遇した。
selectのバグ？
Linux では、 select() がソケットファイルディスクリプタで "読み込みの準備ができた" と報告した場合でも、この後で read を行うと停止 (block) することがある。このような状況は、例えば、データが到着したが、検査でチェックサム異常が見つかり廃棄された時などに起こりえる。他にもファイルディスクリプタが準備できたと間違って報告される状況が起こるかもしれない。 したがって、停止すべきではないソケットに対しては O_NONBLOCK を使うとより安全であろう。
というバグの記述がある。検索すると、天泣記でこの件について少し調べられていた。
はじめはLinuxのこの問題を踏んでしまったのかと思ったが、調べた結果、今回遭遇したのはこの問題ではなかったようだ。
IP_RECVERRソケットオプション
件の問題が起こるプログラムでは、IP_RECVERRソケットオプションが使われていた。このオプションの説明はip(7)のmanにある。この説明を読んだだけではよく分からなかったが、試してみたところ次のように動作するようだ。
- このオプションを設定していると、そのソケットから送信したメッセージに関するICMPエラーを同ソケットで受信できるようになる。
- ICMPエラーを受信した後でそのソケットに対しrecvfrom()やsendto()を呼び出すと、この呼び出しは1度だけエラーになる。このときのエラーコードは（後で書く）。
- 受信したICMPエラーは、recvfrom()やrcvmsg()の呼び出し時に MSG_ERRQUEUE フラグを指定すると読み出すことができる（recvのmanに説明あり）。ソケットには通常のメッセージ用とICMP用の2つの受信用キューがあり、recvfrom()やrcvmsg()はMSG_ERRQUEUEフラグがオフだと通常メッセージ用キューから、オンだとICMP用キューから読み出すという動作をするようだ。
- recvfrom()やrcvmsg()は到着メッセージが無い場合に通常はブロックするが、MSG_ERRQUEUEフラグがオンの場合は到着メッセージが無いとエラーでリターンする。このときのエラーコードは（後で書く）。
- ICMPエラーメッセージをソケットから読み出さない限り、そのソケットに対するselect()はブロックしなくなる。
で、元のプログラムは
- select()
- MSG_ERRQUEUEフラグオフのrecvfrom()
- 上のrecvfrom()がエラーだったらMSG_ERRQUEUEフラグオンのrecvmsg()
という流れになっており、selectを通過した原因がICMPメッセージの到着だった場合にブロックしてしまっていた。これを、
- select()
- MSG_ERRQUEUEフラグオンのrecvmsg()
- 上のrecvmsg()がエラーだったら（ICMPエラーが到着していなかったら）、MSG_ERRQUEUEフラグオフのrecvfrom()
という流れに変更し、対処したつもり。エラーが無い場合にrecvが2回呼ばれるので効率が悪いけれど、この直し方しか思いつかない。
ああ、ソケットをノンブロッキングにすればこんな無駄な処理はしなくていいのか。先に書いたバグの件もあるので、ノンブロッキングI/Oを使うべきなのかなあ。
■ やること
確定申告- 年金
- 税務署へ行く
- PDF生成