mmapのほうがreadより速いという迷信について - kazuhoのメモ置き場
@ITに以下のような記事が出て、 今回からしばらくの間は、まったく逆の例、つまり使うとプログラムの処理性能が上がるというシステムコールを紹介していく。システムコールを呼ぶ回数は少ない方が処理性能は高くなるという原則は変わらないが、呼び出しておくと処理性能が向上するシステムコールというものが存在するのだ。こうしたシステムコールを使わないでいることは、とてももったいない。 今回紹介するシステムコールは「mmap(2)」だ。ここでは詳しく仕組みを解説しないが、mmap(2)は、プログラムの処理性能に必ず良い影響を与える。 やはりあった？ 高速化に効くシステムコール (1/2)：知ってトクするシステムコール（3） - ＠IT それを真に受けたのか、「Go言語でmmapシステムコールを使ったファイル読み込みの高速化検討とC言語のコンパイラの話 - ryochack.blog」のようなブログエントリも
僕が shared_ptr よりも retain() / release() 方式が好きだと思う理由 - kazuhoのメモ置き場
それは、shared_ptr のようなラッパーよりも、オブジェクト自体が参照カウンタをもっているほうがコードが書きやすいから。 たとえば、継承したクラスでオブジェクトの参照カウントをいじることは、shared_ptr では難しい。 shared_ptr を使った場合： class Base { public: virtual void foo() = 0; }; class Derived : public Base { public: virtual void foo() { // ここで自分自身への参照カウンタをインクリメントしたいけどできない… gManager_.register(this); }; // 呼び出し側 obj = shared_ptr<Base>(new Derived()); obj->foo();オブジェクト自体が参照カウンタをもっていれば、このような問題は発生
linux の TCP_DEFER_ACCEPT (サーバサイド) の挙動について - kazuhoのメモ置き場
以前 (2.6.31 まで?) は以下の挙動*1。 最初のペイロードを受信するまで SYN_RECV ステート クライアントの ACK (TCP ハンドシェイクの最後のパケット) を受信していたとしても、SYN-ACK を送り続ける 190 秒たったら、サーバ側は TCP 接続確立失敗と認識 クライアントは SYN-ACK を送ってるから接続できてるつもり TCP の仕様的にどうなの、って話はわかる。ただ、IP 層はパケットロスの可能性があるわけで、インターネットを使っていて、この挙動で問題があるとしたら、それはアプリケーションのバグだと思うけど。一方で、 LAN 上でパケットロスが (ほぼ) 起こらない前提で作ってたら困ることがあるのかなー。Ubuntu の BTS で話が出てるのは、そういうケース (特定のハードウェアロードバランサと TCP_DEFER_ACCEPT を使う Apac
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
