なんか Go で書くのが流行ってるみたいなので - moriyoshiの日記
追記:「kzk's blog」の「Writing TokyoCabinet wrapper for Go language」で紹介御礼。この記事は cgo を使った TokyoCabinet のラッパーの書き方を解説しているので、下記のコードと組み合わせて本当に tc が backend になっている KVS を書いてみるのもよいかも。 『早速 Go 言語を試してみる！』とか。 『Go で無駄にチャンネルを使ってクイックソートのようなものを書いてみた』とか。 こちらはというと、試しに memcache バイナリプロトコルで通信する KVS もどきを書いた。 サーバのイベントループで go すれば全部済むのが楽ちんですね。 追記: HandleConn() の中で、backend_ch を backend との送信と受信両方に使っていたのだけど、ここにあるように、まったく誤りだということが分
select のなかみ - moriyoshiの日記
一応 select(2) も読んであったので説明しとく。 メインループは非常に短いので抜粋。ここにはビットマップの転送処理は含まれていないので注意。max_select_fd() の前後が rcu_read_lock() と rcu_read_unlock() で囲まれているのは、ドキュメント (Documentation/filesystems/files.txt) によると 2.6.12 から RCU をファイルディスクリプタテーブルで利用するようになったため。以前は単なるロックだった。 int do_select(int n, fd_set_bits *fds, s64 *timeout) { struct poll_wqueues table; poll_table *wait; int retval, i; rcu_read_lock(); retval = max_select
epollのなかみ - moriyoshiの日記
よく C10K 問題とかいって epoll(7) の話が出てきて select(2) 遅いね poll(2) 遅いねってなるんだけど、正直なところ、これらのシステムコールを実際に使ってコードを書いてみたひとはどのくらいいるのだろう。ましてや eventpoll が何やってるか知っている人はそんなに多くないんじゃないだろうか。もう O(n) だの O(1) だのって煙に巻かれるのもうんざりだ。 というわけで、2.6.26 の fs/eventpoll.c のコードを読んでみた。正直 Linux カーネルにすごく詳しいわけでもないので、誤りがあったら適宜突っ込んでもらえると幸いです。 前提知識として VFS モジュールがどうなってるかとかは LinuxのFSモジュールを書いてみる LinuxのFSモジュールを書いてみる (その2) のソース中のコメントを追ってもらえればと。 登場する構造体 e
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
