所有異步I/O最終都在輪詢中實現嗎？

Question

雖然異步I/O總是有一個回調形式，我一直在。但是最近我發現一些低級別的實現正在使用輪詢樣式API。

1. kqueue
2. libpq

這使我想到，也許所有（或大部分）的異步I/O（任何文件，插座，馬赫端口等）實現最後以一種投票方式。也許回調形式只是一個抽象的更高級別的API。

這可能是一個愚蠢的問題，但我不知道實際上大多數異步I/O在低級別實現。我剛剛使用了系統級通知，當我看到kqueue - 這是系統通知時，它是輪詢式！

我應該如何理解低級別的異步I/O？ 高級別異步通知如何通過低級別輪詢系統完成？（如果它實際）

Answer 1

在最低（或至少，最低值得看的）硬件水平，異步操作真正是現代操作系統異步的。

例如，當您從磁盤中讀取文件時，操作系統會將您的調用轉換爲read以進行一系列磁盤操作（尋找位置，讀取塊X至Y等）。在大多數現代操作系統中，這些命令被寫入特殊寄存器或主存儲器中的特殊位置，並且磁盤控制器被通知有操作未決。操作系統繼續執行其業務，並且當磁盤控制器完成分配給它的所有操作時，它會觸發interrupt，從而導致請求讀取的線程在其停止的位置拾取。無論您正在查看哪種類型的低級別異步操作（磁盤I/O，網絡I/O，鼠標和鍵盤輸入等），最終都會有一個階段調度到硬件，並且直到硬件伸出並通知操作系統它已完成（通常以中斷的形式），纔會執行原來的「回調」。

這並不是說沒有使用輪詢實現的一些異步操作。一種微不足道（但天真而昂貴）的方式來異步實現任何阻塞操作只是產生一個等待操作完成的線程（可能在緊密循環中輪詢），然後在完成時調用回調。但是，一般來說，操作系統級別的通用異步操作確實是異步的。

還值得一提的是，僅僅因爲API阻塞並不意味着它是輪詢：您可以在異步操作上放置阻塞API，並在同步操作上放置非阻塞API。例如，像select和kqueues之類的東西，線程實際上只是進入休眠狀態，直到發生一些有趣的事情。這種「有趣的東西」以中斷（通常）的形式出現，這被認爲是操作系統應該喚醒相關線程以繼續工作的一種表示。它不只是坐在那裏等待發生的事情。

真的沒有辦法判斷一個系統是否使用輪詢或「真正的」回調（如中斷），只是從它的API，但是，有異步API真正支持異步操作。