io_getevents通知機構は一見したところではかなり見えるので、私はそれを使用することができます。まだ何も見つかりませんでした。 Windowsの場合は簡単です：TransmitFileしかありませんが、必要に応じて非同期に（重複して）動作し、通知メカニズム（IOCP、イベント）で動作します。 Linuxには同等のものが必要ですね。あるいは、私の質問をいくつかの文脈に入れて、Linux上で効率的なファイルサーバを作るにはどうすればよいでしょうか？Linuxにsendfileの非同期バージョンはありますか？
悲しいかな、あなたはLinux上で何も簡単ではなく、間違った状況でブロックすることはほとんどありません（even io_submit）。ご質問への答えでは（タイトルに、メインテキスト内）：
sendfileのない非同期バージョンは、Linuxにありません。 LinuxはWindows（またはFreeBSD）ではありません...ソケットが非ブロッキングである場合は、それらが壊れ...
あなたがリンクしたブログ投稿は、ユーザー空間のスレッドプールでのブロック操作をオフロードすることを示唆しているようですが、これはarvidが[2012年のlibtorrent]（https：//blog.libtorrent）で行ったのと同じことです。org/2012/10/asynchronous-disk-io /）を使用してください。これはまさに私がいくつかのより効率的なAPIのために避けたいのと同じことです。私は、Linuxが6年以上の間に改善されることを期待していました。私はFreeBSDがそれを正しく得ることができたら、なぜLinuxはできないのでしょうか？両方ともPOSIXなので、同じようなハンディキャップを共有しているように感じます。 – purefanatic
また、io_submitは、I/O要求キューや完了キューの充填などの極端な状況下でのみブロックすると考えています。その場合、事実を完了するまで待つ必要があります。 – purefanatic
@purefanatic非常に普及している非同期I/Oフレームワークの欠如は、Linuxの欠点にすぎません。 POSIXはこれに直交するように非同期フレームワークを強制しませんでした。 キャッシュされていないバッファされた読み込みをブロックすることができます。これは、そのようなものではなく、極端ではありません。 – Anon
だ、以上は 'sendfile'（それは、ソケットの「バッファ」に送信することが予定されていたどのくらいのデータを報告しません）しますどちらも。 'sendfile'操作（' epoll'を参照）を続けることができるかどうかを見るためにソケットをポーリングする必要があります。もっと良い方法ですが、これを行うライブラリを使用してください。 – Myst
@Myst Mh、私が非同期I/Oを考えるとき、私は任意の時点で開始し、終了時に通知を受け取る操作を考える。 epoll + sendfileでは、まず送信バッファが利用可能になるまで待つ必要があります。sendfileを呼び出すと、ある量のデータがバッファに（同期的に！）、リンス、リピートされます。 – purefanatic
また、私はsendfileがブロックされていないソケットで使用されていてもブロックされている可能性があり、 'readahead'を使って回避できることを読んでいます：http://brad.livejournal.com/2228488.html これは、実際に作業を行う前に必要なコンテキストスイッチの数が多いため、設計が複雑で待ち時間が長くなります。私は本当に "ノンブロッキング"のアプローチを満足するものではありません。 – purefanatic