apue上提到了低速的系統呼叫 解釋很長很麻煩 第三版 260頁
我只是簡單的理解為能夠發生阻塞並且阻塞時間夠長且有可能永遠阻塞的系統呼叫
當這些函式處於阻塞期，恰好捕捉到乙個訊號，則該系統呼叫返回出錯，起errno設定為eintr;
而我們希望重啟這些函式則出線了這樣的**
again:
if(( n == read(fd,buf,bufsize)) < 0)
if(errno == eintr)
goto again:
然而隨著時間的流失，更方便的方法出來了。那就是自啟動的系統呼叫
包括：ioctl read readv write writev wait waitpid
因為這也許會帶來問題，所以程序可以控制每個訊號中斷這些系統呼叫後，是否重啟。具體方式sigaction函式用sa_interrupt巨集決定
linux中斷與系統呼叫
1.系統使用巨集syscallx 將相應的系統呼叫定義為其同名函式。呼叫中斷int 0x80.並將引數傳送到相應的暫存器中，供entry system call 使用。2.進入entry system call 中，當系統呼叫合法時，根據索引值，在sys call table中找到相應的實際服務程式...
訊號之不可靠的訊號及中斷的系統呼叫
在早期的unix版本中，訊號是不可靠的。不可靠在這裡指的是，訊號可能會丟失 乙個訊號發生了，但程序卻可能一直不知道這一點。早期版本中的乙個問題是在程序每次接到訊號對其進行處理時，隨即將該訊號動作復位為預設值 經測試，發現我現在用的red hat linux 2.6.18也是這樣處理的。在描述這些早期...
可被中斷的系統呼叫
早期的unix系統，如果程序在乙個 慢 系統呼叫中阻塞時，捕獲到乙個訊號，這個系統呼叫被中斷，呼叫返回錯誤，設定errno為eintr。這表明，不是這個系統呼叫錯出了，而是被中斷了，需要再次啟動。系統呼叫被分為慢系統呼叫和其他兩大類別。慢系統呼叫可以被永久阻塞，包括以下幾個類別 1 讀寫 慢 裝置 ...