図解求む。 以下「プロトコル処理」と「メッセージ処理」を分けて扱っているが、この差が顕著に出るのは全文検索エンジンや非同期ジョブサーバーなど、小さなメッセージで重い処理をするタイプ。ストリーム指向のプロトコルの場合は「プロトコル処理」を「ストリーム処理」に置き換えるといいかもしれない。 シングルスレッド･イベント駆動 コネクションN：スレッド１。epoll/kqueue/select を１つ使ってイベントループを作る。 マルチコアCPUでスケールしないので、サーバーでは今時このモデルは流行らない。 クライアントで非同期なメッセージングをやりたい場合はこのモデルを使える： サーバーにメッセージを送信 イベントハンドラを登録；このときイベントハンドラのポインタを取っておく イベントハンドラ->フラグ がONになるまでイベントループを回す イベントハンドラ->結果 を返す １コネクション１スレッ
まだまだ未完成で半分アイディアだけなのですが、なかなか進まないのでとりあえず公開してみます。CodeRepos:/lang/c/mpio/trunk/mp いわゆるlibeventのようなものなのですが、C++で書かれていて、より使いやすく、より最適化が効きやすいようになっています。 以下のような特徴があります（目指しています）。 オーバーヘッドの少ない低水準レイヤー、使いやすい高水準レイヤーという形でレイヤー構造になっている better Cなコードにもある程度なじむ メモリ管理機能を内蔵している ヘッダファイルをincludeするだけで使える（ライブラリをリンクしなくて良い） ライブラリ自体のコードが短く、モジューラブル 低水準なレイヤーから順に、mp::event、mp::dispatch、mp::io、mp::asioがあります。 mp::event OS依存のIO多重化システムコ
*BSD で kqueue・kevent を使ってみよう select() の欠点 select() は複数のディスクリプタをポーリングできる便利なシステムコールです。 しかしパフォーマンスはよくありません。理由は以下の通りです。 ユーザプロセスは、監視対象のディスクリプタ一覧をユーザ領域からカーネル領域にコピーする必要がある。 カーネルがポーリング結果をユーザ領域に返す際もコピーしなければならない。 カーネルは、ポーリング対象のディスクリプタを知るために、配列の全要素を調べなければならない。 ユーザプロセスも、入出力可能なディスクリプタを知るために、配列の全要素を調べなければならない。 上記の作業は、select() を発行するたびに毎回行わなければならない。 select() のパフォーマンスが悪いことは広く知られていたので、 各 OS でいろいろな取り組みが行われてきました。 Sol
ネットワークで通信するプログラムを書いていると、ファイルディスクリプタ（ネットワークならソケット）をselectやpollで監視して、パケットが届いたら何かする、ということが良くあります。 しかしselectやpollは、*BSD で kqueue・kevent を使ってみようで書かれているように、どうも遅いらしい。C10K問題が取りざたされている昨今、Linuxにはepoll、BSDにはkqueue、Solarisには/dev/pollというより高速な仕組みが用意されているのですが、epollを使ってしまうとLinuxでしか動かないし、kqueueで書くとBSDでしか動かない。 というわけで、epollもkqueueも同じインターフェースで使えて、#defineで簡単に中身を切り替えられると嬉しい、とは誰しも一度は思うはず。そうに違いない。 もちろん先人も同じことを考えており、libev
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
