コルーチンをベースとして使用し、おもちゃのスケジューラーを実装することについての非常に基本的なことを知っています。しかし、私はそれが全体として非同期スケジューラーについて過度に単純化された見方だと思います。私の考えには、一組の穴が欠けています。
アイドル/待機中のスケジューラーをCPUが実行しないようにするにはどうすればよいですか?スリープするファイバーもあれば、オペレーティングシステムからの入力を待つファイバーもあります。
コルーチンをベースとして使用し、おもちゃのスケジューラーを実装することについての非常に基本的なことを知っています。しかし、私はそれが全体として非同期スケジューラーについて過度に単純化された見方だと思います。私の考えには、一組の穴が欠けています。
アイドル/待機中のスケジューラーをCPUが実行しないようにするにはどうすればよいですか?スリープするファイバーもあれば、オペレーティングシステムからの入力を待つファイバーもあります。
io操作をイベントベースのインターフェイス(選択/ポーリング)に多重化する必要があるため、OSを活用して待機を実行しながら、他のファイバーをスケジュールすることができます。select / pollにはタイムアウト引数があります-スリープしたいファイバの場合、select/pollのオプションを使用してスリープコールをエミュレートするプライオリティキューを作成できます。
ブロッキング操作(読み取り/書き込み/スリープなどを呼び出す)を実行するファイバーを提供しようとしています。ネイティブスレッドで各ファイバーをスケジュールしない限り、直接機能しません。これは、目的を上回っています。
実用的な実装については、http://swtch.com/libtask/を参照してください。
おそらく、setcontextファミリーの関数(http://en.wikipedia.org/wiki/Setcontext)を確認する必要があります。これは、アプリケーション内で、ブロック(読み取り、書き込み、スリープなど)する可能性のあるすべての関数を非同期形式に再実装してスケジューラーに戻る必要があることを意味します。
「スケジューラファイバー」のみが、select()、poll()、またはepoll()を使用して完了イベントを待機します。これは、スケジューラーがアイドル状態の場合、プロセスはselect / poll / epoll呼び出しでスリープ状態になり、CPUを占有しないことを意味します。
答えるのは少し遅いですが、私はlibevfibersと呼ばれるCのファイバーライブラリの実用的な実装を持っていることを述べたいと思います。
若いプロジェクトであるにもかかわらず、本番環境で使用されています。ソケットの読み取り/書き込みなどの従来の非同期操作に対するソリューションを提供するだけでなく、非ブロッキング方式でファイルシステムIOに対処します。このプロジェクトは、libcoro、libev、libeioの3つの優れたライブラリを活用しています。
コルーチンを使用して制御フローを制御することもできます。それらの作成をサポートするライブラリはBOOST.ASIOです。
良い例はここにあります:Boost Stackful Coroutines
実装の観点からは、非同期イベントループの実装から始めることができます。次に、非同期イベントハンドラーを使用して対応するファイバーに切り替えることにより、その上にファイバースケジューリングを実装できます。
スリープ/待機中のファイバーは、現時点ではスケジュールされていないことを意味します。代わりに、イベントループに切り替わります。
ところで、実際のコードを探しているなら、見てくださいhttp://svn.cmeerw.net/src/nginetd/trunk/これはまだ進行中ですが、マルチスレッドイベントループ(Win32 I / O完了ポートまたはLinuxのエッジを使用)の上にファイバースケジューラを実装しようとします-トリガーされたepoll)。