async_io

1. I/O function 需要 non-blocking 不是為了『查詢狀態』,是因為會有 spurious wake up 即人家跟你講『可能有資料可以搬』結果沒有的時候,還要不 block 住。
2. non-blocking 函式跟 callback 不是同一個層次的東西,不是解決同一個問題的兩種相提並論的解法。從計算機組織與組合語言的層次去看,作業系統底層的 async I/O 實作不會是在 CPU 高權限模式就跳去執行某阿貓阿狗 app 的 callback code,否則無法實作權限保護
3. (承上)有個相關的觀念問題: callback 在哪個 thread 發生?

若 callback 內容不是很耗 CPU (例: 接到 network response 更新 UI ) 較常見是用 select / poll /epoll 收到 I/O event 的 thread 直接呼叫 callback 了。從效率上看,『接到 I/O event』時你的 thread 已經醒過來在跑了,許多時候不想再將工作多傳一手,再跑 scheduler。

若系統 response time 一定要短,在寫 code 的人都有先好好學目前 code base 內 concurrency 機制該怎麼用,則如你所說。

但實務上,我有不只一次 慘痛 經驗: concurrency 不太熟的同事覺得『這個 function 可能會有點慢,我們把它 post 到 thread pool 去跑 / 局部開一個新的 thread 去跑』結果 task 的相依性、系統的可預測性完全亂掉。若你 team 上有新人加入,你跟他說『啊!你應該 deletegate 去一個 worker thread 跑』。新人寫出來的 code 可能是自己 pthread_create() 也可能會把系統的 thread pool 鎖死。這邊 .NET 與 Java 的高階 library 還是有幫助:
http://msdn.microsoft.com/en-us/library/dd460717.aspx
http://docs.oracle.com/javase/tutorial/essential/concurrency/forkjoin.html
C / C++ 每次學一個新的 library 或 code base effort 不小
Reference:
async io

network programming 參考資料整理最好的還是 http://www.kegel.com/c10k.html
C 語言的 async I/O library design 可參考 Node.js 用的 libuv (http://nikhilm.github.com/uvbook/introduction.html)
它比 libev 多支援了 Windows IOCP style 的 async I/O.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License