5

私は、複雑なマルチスレッド実装から、ステートマシンを使用して接続されているセッションの状態を追跡するシングルスレッド/シングルプロセス実装に移行する TFTP 実装に取り​​組んでいます。TFTP は十分に単純であり、同時セッションの数が十分に少ないため、コード サイズと複雑さを大幅に節約する以外に、ソフトウェアへの影響は実際にはありません。

もちろん、他のセッションが接続されているときに、1 つのセッションだけをブロックすることはできません。これを改善するために、私の最初の考えは POSIX AIO でしたが、いくつかの調査の結果、それは

  • 不十分に文書化されており、完全ではありません
  • ディスク I/O でのみ動作し、ソケットをサポートしないか、ソケットで動作するが読み取り/書き込みのみ - リスニング用ではありません。

このリンク ( http://davmac.org/davpage/linux/async-io.html ) に例が含まれていますが、他にも見つけました。'08の以前の stackoverflow の投稿 ( POSIX 非同期 I/O (AIO) のステータスとは? ) で、いくつかの追加の視点が提供されました。

C 開発者にとって、AIO は人々が主張するほどまだ壊れているのでしょうか? 人々は本当に AIO を使用せず、主にポーリング/選択または有限サイズのスレッド プールに固執しますか?

4

5 に答える 5

1

不十分な文書化は確かに当てはまります。

ほとんどの人はpoll()/を使い続けますが、それselect()は単純に、これらが十分に理解され、十分にテストされ、十分に文書化され、十分にサポートされているからです。私があなただったらselect()、やむを得ない理由がない限り、使用します。

于 2010-07-07T01:26:18.293 に答える
0

POSIX AIOについての質問には答えられませんが、イベントにはlibevを使用しました。小さく、速く、シンプル。poll/selectの代わりにIOの優れたラッパーを作成します。

于 2010-07-06T17:40:28.480 に答える
0

クロスプラットフォームの非同期ソケットライブラリについては、Boost.Asioを検討してください。優れた例があり、広範囲にわたって文書化されています。

于 2010-07-06T17:07:23.160 に答える
0

ディスクの場合、1) 独自のキャッシュを使用する、2) ダーティ ページへの影響を制御する、または 3) IO 優先順位を使用する場合を除き、バッファリングされた読み取り/書き込みではなく、なぜ AIO を使用する必要があるのですか?

目的がコードのリファクタリングのみである場合、現在のバージョンでキャッシュを使用する可能性が高いためです。バッファリングされた IO からダイレクト IO への変更は大きな変化です。

たとえば、1.5G の RAM を搭載した ext3/SSD/noop では、300Mb のストリーム書き込みを実行する 3 つのスレッドだけで、小さな書き込みと読み取りが不足します。違反者をダイレクト IO に切り替えると修正されますが、書き込みには永遠に時間がかかります。

于 2010-08-20T17:24:06.777 に答える
0

aio の問題はプラットフォームに依存するため、決定の大きな部分は、対象とするプラットフォームです。品質は大きく異なり、場合によっては、ポーリング/選択タイプの呼び出しに関して実装されます。

Unix プラットフォームでは、この種のことのために、poll/select または kevent/kqueue や epoll などの同様のインターフェイスを使用する傾向があります。

aio インターフェースには問題があり、aio_waitcomplete() のような追加と、aio と kqueues の統合が違いを生みます。

大量の I/O を処理するための多数のスレッドは、適切なアプローチではありません。

于 2010-07-07T14:15:18.807 に答える