A. 哪位知道怎麼設計linux下的非阻塞定時程序啊
linux下不是有現成的非同步定時器么，使用setitimer。linux下定時就3種方法，不使用setitimer的話，就是用sleep讓進程休眠或者使用gettimeofday獲取時間並比較超時。
B. linux下設置recvfrom為非阻塞
可以使用
1 select pselect
2 poll
3可以使用fcntl給文件描述符添加O—UNBLOCK
C. 如何設置linux socket為非阻塞
int flags = fcntl(socket, F_GETFL, 0); fcntl(socket, F_SETFL, flags | O_NONBLOCK);
D. linux網路編程中阻塞和非阻塞socket的區別
阻塞的是意思是這樣：read函數讀的時候，如果此時數據包沒有來，那就程序就會暫停執行，在read函數裡面暫停。它如何繼續執行呢？那就是數據包來之後它繼續執行。非阻塞就是說，如何執行read函數的時候，數據包沒有，那麼read函數返回沒有讀到任何東西，如果執行read函數時候恰好有數據包，那麼read函數將返回讀到的數據包。也就是說，阻塞的socket使用read的時候，你都能保證讀到數據包。而非阻塞就不一定了，所以往往非阻塞需要配合循環，不停的讀，或者設置一個超時。如果讀了幾次，或者等待了多少秒沒有讀到，就超時。阻塞的，無法控制時間。
E. linux下阻塞，非阻塞，輪詢
用淺顯的話來說吧。
在一般的情況下，在系統和應用程序之間有一個請求隊列層，起到調度的作用，應用程序不會直接訪問系統，而是把訪問請求放進隊列層中；而系統也在不停的從隊列層中提取請求然後不斷的分發執行，這種請求方式就是阻塞式訪問。
但是有些特殊的請求是不允許停止和等待的，這種請求就不會被放入隊列層中，而是直接插入到系統的當前處理的前端，而被優先執行，這種請求方式就是非阻塞式訪問。
這二者的區別是由於其工作性質決定的，單純從理論角度來說，與CPU佔用等沒有任何關系，CPU佔用只和和演算法復雜度有關。
一般非阻塞功能都是使用在系統級的請求上，比如某些驅動級的中斷請求或實時類請求，因為繞過了請求隊列，編制不良的非阻塞程序可能會導致系統失去響應。
F. linux waitpid怎麼設置成非阻塞
「非阻塞」和「延時」這兩個本來就是沖突的吧。 不吞食CPU但是要讓線程掛起一段時間，方法自然是要求操作系統在一段時間的線程調度內不要給當前線程分配時間片 「非阻塞」……
G. 如何linux 程序中啟用其他進程，非阻塞，非popen
在Linux程序中啟動其他進程可以用system函數，這個函數會等待它啟動的那個程序結束才返回，所以它是一個阻塞調用。還有一種非阻塞的啟動外部程序的方法，稍微復雜一點，是運用Linux的exec系列函數，之所以說系列函數是因為有不同的變種，只是參數的形式不同而已，其實完全是一樣的，exec系列函數的行為是將當前進程替換成要啟動的那個新進程，這里的當前進程就是你編寫的程序，新進程啟動後調用exec函數的進程就不存在了，exec系列函數調用之後的代碼也不會再執行了。所以，exec系列函數的正確使用方法是在程序中進行fork調用復制進程，然後把exec函數的調用語句放在fork的子進程裡面，注意子進程中exec函數調用的後面就不要寫其他功能的代碼了，因為exec函數後面的語句不會被執行。
H. linux阻塞與非阻塞I/O
阻塞操作是指在執行設備操作時，若不能獲得資源，則掛起進程直到滿足可操作的條件後再進行操作。被掛起的進程進入睡眠狀態，被從調度器的運行隊列移走，直到等待的條件被滿足。而非阻塞操作的進程在不能進行設備操作時，並不掛起，它要麼放棄，要麼不停地查詢，直至可以進行操作為止。
驅動程序通常需要提供這樣的能力：當應用程序進行read（）、write（）等系統調用時，若設備的資源不能獲取，而用戶又希望以阻塞的方式訪問設備，驅動程序應在設備驅動的xxx_read（）、xxx_write（）等操作中將進程阻塞直到資源可以獲取，此後，應用程序的read（）、write（）等調用才返回，整個過程仍然進行了正確的設備訪問，用戶並沒有感知到；若用戶以非阻塞的方式訪問設備文件，則當設備資源不可獲取時，設備驅動的xxx_read（）、xxx_write（）等操作應立即返回，read（）、write（）等系統調用也隨即被返回，應用程序收到-EAGAIN返回值。
在阻塞訪問時，不能獲取資源的進程將進入休眠，它將CPU資源「禮讓」給其他進程。因為阻塞的進程會進入休眠狀態，所以必須確保有一個地方能夠喚醒休眠的進程，否則，進程就真的「壽終正寢」了。喚醒進程的地方最大可能發生在中斷裡面，因為在硬體資源獲得的同時往往伴隨著一個中
斷。而非阻塞的進程則不斷嘗試，直到可以進行I/O。
I. linux網路編程，為什麼要將文件描述符設置成非阻塞模式
非阻塞IO 和阻塞IO：
在網路編程中對於一個網路句柄會遇到阻塞IO 和非阻塞IO 的概念, 這里對於這兩種socket 先做一下說明：
基本概念：
阻塞IO::
socket 的阻塞模式意味著必須要做完IO 操作（包括錯誤）才會
返回。
非阻塞IO::
非阻塞模式下無論操作是否完成都會立刻返回，需要通過其他方
式來判斷具體操作是否成功。(對於connect，accpet操作，通過select判斷，
對於recv，recvfrom，send，sendto通過返回值+錯誤碼來判斷)
IO模式設置：
SOCKET
對於一個socket 是阻塞模式還是非阻塞模式的處理方法::
方法：：
用fcntl 設置;用F_GETFL獲取flags,用F_SETFL設置flags|O_NONBLOCK;
同時，recv,send 時使用非阻塞的方式讀取和發送消息，即flags設置為MSG_DONTWAIT
實現
fcntl 函數可以將一個socket 句柄設置成非阻塞模式:
flags = fcntl(sockfd, F_GETFL, 0); //獲取文件的flags值。
fcntl(sockfd, F_SETFL, flags | O_NONBLOCK); //設置成非阻塞模式；
flags = fcntl(sockfd,F_GETFL,0);
fcntl(sockfd,F_SETFL,flags&~O_NONBLOCK); //設置成阻塞模式；
並在接收和發送數據時:
將recv, send 函數的最後有一個flag 參數設置成MSG_DONTWAIT
recv(sockfd, buff, buff_size,MSG_DONTWAIT); //非阻塞模式的消息發送
send(scokfd, buff, buff_size, MSG_DONTWAIT); //非阻塞模式的消息接受
普通文件
對於文件的阻塞模式還是非阻塞模式::
方法1、open時，使用O_NONBLOCK；
方法2、fcntl設置，使用F_SETFL，flags|O_NONBLOCK；
消息隊列
對於消息隊列消息的發送與接受::
//非阻塞 msgsnd(sockfd,msgbuf,msgsize(不包含類型大小),IPC_NOWAIT)
//阻塞 msgrcv(scokfd,msgbuf,msgsize(**),msgtype,IPC_NOWAIT);
讀
阻塞與非阻塞讀的區別: //阻塞和非阻塞的區別在於沒有數據到達的時候是否立刻返回．
讀(read/recv/msgrcv):
讀的本質來說其實不能是讀,在實際中, 具體的接收數據不是由這些調用來進行,是由於系統底層自動完成的。read 也好,recv 也好只負責把數據從底層緩沖 到我們指定的位置.
對於讀來說(read, 或者recv) ::
阻塞情況下::
在阻塞條件下，read/recv/msgrcv的行為::
1、如果沒有發現數據在網路緩沖中會一直等待，
2、當發現有數據的時候會把數據讀到用戶指定的緩沖區，但是如果這個時候讀到的數據量比較少，比參數中指定的長度要小，read 並不會一直等待下去，而是立刻返回。
read 的原則::是數據在不超過指定的長度的時候有多少讀多少，沒有數據就會一直等待。
所以一般情況下::我們讀取數據都需要採用循環讀的方式讀取數據，因為一次read 完畢不能保證讀到我們需要長度的數據，
read 完一次需要判斷讀到的數據長度再決定是否還需要再次讀取。
非阻塞情況下::
在非阻塞的情況下，read 的行為::
1、如果發現沒有數據就直接返回，
2、如果發現有數據那麼也是採用有多少讀多少的進行處理．
所以::read 完一次需要判斷讀到的數據長度再決定是否還需要再次讀取。
對於讀而言:: 阻塞和非阻塞的區別在於沒有數據到達的時候是否立刻返回．
recv 中有一個MSG_WAITALL 的參數::
recv(sockfd, buff, buff_size, MSG_WAITALL),
在正常情況下recv 是會等待直到讀取到buff_size 長度的數據，但是這里的WAITALL 也只是盡量讀全，在有中斷的情況下recv 還是可能會被打斷，造成沒有讀完指定的buff_size的長度。
所以即使是採用recv + WAITALL 參數還是要考慮是否需要循環讀取的問題，在實驗中對於多數情況下recv (使用了MSG_WAITALL)還是可以讀完buff_size，
所以相應的性能會比直接read 進行循環讀要好一些。
注意:: //使用MSG_WAITALL時，sockfd必須處於阻塞模式下，否則不起作用。
//所以MSG_WAITALL不能和MSG_NONBLOCK同時使用。
要注意的是使用MSG_WAITALL的時候，sockfd 必須是處於阻塞模式下，否則WAITALL不能起作用。
寫
阻塞與非阻塞寫的區別: //
寫(send/write/msgsnd)::
寫的本質也不是進行發送操作,而是把用戶態的數據 到系統底層去,然後再由系統進行發送操作,send，write返回成功，只表示數據已經 到底層緩沖,而不表示數據已經發出,更不能表示對方埠已經接收到數據.
對於write(或者send)而言，
阻塞情況下:: //阻塞情況下，write會將數據發送完。(不過可能被中斷)
在阻塞的情況下，是會一直等待，直到write 完，全部的數據再返回．這點行為上與讀操作有所不同。
原因::
讀，究其原因主要是讀數據的時候我們並不知道對端到底有沒有數據，數據是在什麼時候結束發送的，如果一直等待就可能會造成死循環，所以並沒有去進行這方面的處理；
寫，而對於write, 由於需要寫的長度是已知的，所以可以一直再寫，直到寫完．不過問題是write 是可能被打斷嗎，造成write 一次只write 一部分數據, 所以write 的過程還是需要考慮循環write, 只不過多數情況下一次write 調用就可能成功.
非阻塞寫的情況下:: //
非阻塞寫的情況下，是採用可以寫多少就寫多少的策略．與讀不一樣的地方在於，有多少讀多少是由網路發送的那一端是否有數據傳輸到為標准，但是對於可以寫多少是由本地的網路堵塞情況為標準的，在網路阻塞嚴重的時候，網路層沒有足夠的內存來進行寫操作，這時候就會出現寫不成功的情況，阻塞情況下會盡可能(有可能被中斷)等待到數據全部發送完畢， 對於非阻塞的情況就是一次寫多少算多少,沒有中斷的情況下也還是會出現write 到一部分的情況.
J. 怎麼將linux下的怎麼將文件描述符變成非阻塞
怕 ulimit -SHn 51200 失效 所以 我先修改了 /etc/security/limits.conf 有在 /etc/profile 和 /etc/rc.local 都添加了 ulimit -SHn 51200 profile 是 用戶登錄 就自動調用的 rc.local 是 開機自動調用 這樣就不怕 失效了