PIPEによるプロセス間通信とselect, poll, epollの話 - c-bata web
エキスパートPythonプログラミング 改訂2版 (アスキードワンゴ) 作者: Michaｌ Jaworski,ＴａｒｅｋＺｉａｄｅ,稲田直哉,芝田将,渋川よしき,清水川貴之,森本哲也出版社/メーカー: ドワンゴ発売日: 2018/02/26メディア: Kindle版この商品を含むブログを見る 先日、 tokibito 先生(id:nullpobug)と勉強していたpipe, select, poll, epollあたりについてメモ。 os.fork os.fork : 子プロセス(child process)をつくれる。 import os a = 0 print(a) os.fork() a += 1 print(a) 子は親の複製。親のデータ、ヒープ、スタックの各空間の複製を取得。 メモリのこれらの部分は共有されないので、実行結果は次のようになる(テキストセグメントは共有される)。
並列イベント駆動I/Oフレームワーク「mpio」リリース - Blog by Sadayuki Furuhashi
分散KVS kumofs のコードは、全体で約2万行です*1。 そのうち、ネットワークI/Oやプロトコルに関するコードは約1万行*2で、全体の約半分を占めています。 ロジックは残りの半分*3だけで実装されています。 この実例から分かりますが、kumofsのような分散アプリケーションを開発するにはI/O周りの実装が大変で、とてつもなく大きな障壁になっています。*4 さらに今日では、性能を稼ぐためにマルチスレッド化が必須です。また、多数のクライアントを少ないリソースで効率よく相手にするには、非同期・イベント駆動型のアーキテクチャも必要になります。さらに、究極的な性能を達成すべく GC を利用しない C++ においては、実装のみならず設計も大変です。 これに加えてソケットAPIの難解な挙動に対処にしなければならないため、C言語やC++によるネットワークプログラミングは、vimの使いこなしなどと同
最速TCPサーバーの件でちょっと分からないこと(解決) - kuenishi's blog
epoll + fork 版サーバーは、予想通り thread 版を大きく 突き放すスコアをたたき出し、しかもまだCPU使用率には余力が残っていました。CPUを使い切れて いないのは、多分実験機のNICの Broadcom BCM5754 が複数コアに割り込みを分散する機能を もっていないためで、NICを増やしたり割り込み分散機能のあるNICを使えばもっと 差が広がると思います。 @mathaneさんはepoll+forkが最速になるだろうと予想していて、結果も予想通りになっているわけですが。Linuxカーネルからみるとネイティブスレッドもふつうのプロセスと同様にLWPと1:1対応しているわけでfork版とコンテキストスイッチのオーバーヘッドはそう変わらないはずだ。むしろ別プロセスをコンテキストスイッチする方が仮想メモリ空間の切り替えの分だけ重そうだから、僕の知識の範囲ではthread版の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
