ネットワークIOについて - sdyuki-devel
ある日のtwitter。 write()のエラーをコールバックする必要があるのかどうか。write()が失敗するのはカーネル内の出力バッファへのコピーが拒否されたときで、送信エラーが発生したときではないわけで。 実際に送信エラーが発生すれば、今度はread()が失敗するはず。特にTCPだったらwrite()が失敗しておきながらread()が失敗しないのは考えにくい…。保証はないけども…。 つまり宛先ノードが落ちたとかは、read()の失敗で検出できる。何ならwrite()が失敗したらファイルディスクリプタをclose()してしまえば、確実にread()が失敗する。 というわけで、送信専用のソケットでread待ちをしていない限りは、writeの失敗をコールバックする必要は無いんじゃないか。 でもwrite()失敗したときにclose()してしまうのは、別の問題が発生するかもしれない。clos
ホームページ作成ツール - sdyuki-devel
Webブラウザを最初に起動したときに出てくるページの方のホームページ。 そんなツールがあったら面白いんじゃないかというアイディア。 今時、検索エンジンは右上にあるし、ポータルサイトのトップページはごちゃごちゃして目障りだし、ニュースサイトはRSSリーダがあるし、実は皆さんホームページが余っているじゃなかろうか。（自分だけだったりして） というわけで、ブラウザを起動すると、左上にカレンダーとTODO、上にデジタル時計＋ファジー時計、なんてのは普通だけど、左にソースコードリポジトリ、右にmixiのトップページ（の欲しいところだけ）、右下にRSSとか。で、下はシェル。これはいいな…。 真ん中には空きスペースがあって、周りにアイコンがいろいろある。そのアイコンを真ん中のスペースにアイコンをドラッグして持ってくると、そのアイコンが示すサイトが表示されたり、他のモジュールが表示されたりする。そこは ぐ
ネットワークプログラムのI/O戦略 - sdyuki-devel
図解求む。 以下「プロトコル処理」と「メッセージ処理」を分けて扱っているが、この差が顕著に出るのは全文検索エンジンや非同期ジョブサーバーなど、小さなメッセージで重い処理をするタイプ。ストリーム指向のプロトコルの場合は「プロトコル処理」を「ストリーム処理」に置き換えるといいかもしれない。 シングルスレッド･イベント駆動 コネクションN：スレッド１。epoll/kqueue/select を１つ使ってイベントループを作る。 マルチコアCPUでスケールしないので、サーバーでは今時このモデルは流行らない。 クライアントで非同期なメッセージングをやりたい場合はこのモデルを使える： サーバーにメッセージを送信 イベントハンドラを登録；このときイベントハンドラのポインタを取っておく イベントハンドラ->フラグ がONになるまでイベントループを回す イベントハンドラ->結果 を返す １コネクション１スレッ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
