今天看linux驅動時，發現乙個erestartsys的返回，是在阻塞中看到的， erestartsys
ldd3說的也不是很清楚，後來會反覆查閱，自己猜測在wake_up_interruptible的時候，這個時候被其他訊號喚醒，由於不是本身
所喚醒的，這個時候，依然從我們的的系統呼叫中返回，但是上層在處理完其他訊號後，還會再次呼叫我們這個系統呼叫。
摘自：
關於 erestartsys 到底是什麼意思
經常我們在睡眠的**中 會看到這樣的例子：
if (signal_pending(current))
關於 erestartsys 到底是什麼意思? 通過下面的論壇可以了解一下。
這個過程，不必深究， 你就知道上層的庫函式 ，當收到 -erestartsys 這個返回值後，對於linux來講，會自動的重新呼叫這個呼叫就可以了。
， 這麼寫就可以了。
摘自：quote:
原帖由
zhn636 於 2007-9-3 16:54 發表
1，當乙個系統呼叫處於等待狀態時，此時產生了訊號，那末是先返回系統呼叫再處理訊號，還是先處理訊號再讓系統呼叫返回？
2，當系統呼叫未處於等待狀態時，比如說read呼叫正在往緩衝區拷貝資料，此時產生了訊號，那末這個訊號必須等到拷貝完資料並且read返回以後才進行處理？
情景分析：
1，當乙個系統呼叫處於等待狀態時，比如等待輸入緩衝區不為空，此時產生了訊號，這個訊號僅僅是在該程序的thread_info結構中標識一下，就是所謂的「發訊號」，然後喚醒程序的系統呼叫，系統呼叫醒來後，此時僅僅用signal_pending()檢查一下是否有訊號，這裡，不處理訊號的，當此時有訊號，系統呼叫返回erestartsys，在從系統呼叫的返回使用者空間時，會根據thread_info中訊號標識位呼叫相應的訊號處理函式，這裡就是所謂的「接收訊號」，對於linux，上層庫函式會根據系統呼叫的erestartsys返回值重啟該系統呼叫，而對於solaris則會讓系統呼叫失敗，在linux中，重啟的系統呼叫會再次檢查緩衝區，為空，說明剛才的訊號不是緩衝區有資料了的訊號，繼續等待，重複剛才的過程，不為空，就可以直接處理資料，系統呼叫正常結束
注：「發訊號」僅僅是標識thread_info，系統呼叫醒來檢查訊號，僅僅是signal_pending()判斷一下thread_info中是否有任何乙個訊號標識，真正的「接受訊號」是從系統呼叫返回時，或者異常處理程式返回時，比如每次的時鐘中斷處理函式返回時，檢查thread_info中具體哪個訊號，呼叫相應處理程式
補：對於solaris，上面的情況，read在等，緩衝區滿了，喚醒read程序，不同通過我們這裡所談的「訊號」
還有就是訊號阻塞和排隊的問題
從系統呼叫或者終端處理程式返回時，檢查thread_info中訊號標識，呼叫相應處理程式時會先清掉該標識，在處理過程中，又來了相同的訊號，則這個訊號會被阻塞，意思是在執行這個訊號處理程式過程中引起的系統呼叫返回時，或者中斷處理程式返回時，儘管檢查thread_info中該訊號被標識，也不會再次呼叫該訊號的處理程式，這個訊號就被「阻塞」了，此時還在該訊號處理程式中，很不幸，如果這個訊號又來了，此時thread_info中該訊號位已經被標識了，就1位的空間，這個訊號就相當於丟失了，換句話說，第二個訊號後面所有前仆後繼的兄弟都不會被「排隊」，會丟失
乙個簡單的Linux字元驅動
這個是win驅動課的作業，題目是設計乙個通用的io埠讀寫驅動，因為我的電腦配置太低無法執行虛擬機器，就用linux完成了作業。read和write的處理併發讀寫的部分來自ldd3。1.驅動程式 通用io埠讀寫驅動 include include include include include inc...
乙個簡單的linux核心驅動
一，核心結構簡單概述 上層程式操作裝置驅動簡單概述 在使用者空間使用相關的c庫，比如open函式會造成乙個中斷，系統會去呼叫sys call函式 系統呼叫 然後會去呼叫相關的sys open函式，在核心空間的時候會去驅動鏈表裡面查詢對應的外設驅動，我們編寫完驅動程式，載入到核心，核心會去呼叫相關的驅...
第乙個linux 驅動
以前看過很多次linux相關的資料，一直沒親自動手寫，今天通過半天努力，終於完成了乙個自己的linux小驅動 hello.c include include module license dual bsd gpl static int hello init void static void hell...