• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            Onway

            我是一只菜菜菜菜鳥...
            posts - 61, comments - 56, trackbacks - 0, articles - 34

            APUE第十章 信號 筆記

            Posted on 2011-12-04 13:48 Onway 閱讀(413) 評論(0)  編輯 收藏 引用 所屬分類: 使用說明
            2011-11-24 第十章 信號
            第一節


            第二節
            1,linux將信號定義在<bits/signum.h>中。signal函數聲明在<signal.h>中。<signal.h>include<bits/signum.h>。
            2,程序要求內核對信號的處理可以是三種方式:忽略,捕捉和默認。
            3,SIGKILL和SIGSTOP信號不能忽略,也不能捕捉。


            第三節
            1,signal在linux的聲明
            typedef void (*__sighandler_t) (int);
            extern __sighandler_t signal (int __sig, __sighandler_t __handler)
                 __THROW;
            2,SIG_ERR,SIG_DFL和SIG_IGN的定義
            #define SIG_ERR ((__sighandler_t) -1) /* Error return.  */
            #define SIG_DFL ((__sighandler_t) 0) /* Default action.  */
            #define SIG_IGN ((__sighandler_t) 1) /* Ignore signal.  */
            懷疑書上有錯:
            ”如果查看系統的頭文件<signal.h>,則很可能會找到下列形式的聲明:
            #define SIG_ERR (void (*)())-1
            #define SIG_DFL (void (*)())0
            #define SIG_IGN (void (*)())1
            似乎應該是 (void (*)(int))這個函數指針類型。


            第四節 不可靠信號
            1,早期的unix版本,信號是不可靠的。
            兩個原因:
            一,信號動作自動復位為默認值。若信號處理期間重新進行信號動作注冊,則會存在一個時間窗口。該時間窗口可能會讓信號的默認動作終止程序。
            二,不能阻塞信號。若自定義信號發生標記,同樣存在一個時間窗口。


            第五節 中斷的系統調用
            1,低速系統調用是可能會使進程永遠阻塞的一類系統調用。
            2,早期unix特性:如果進程執行一個低速系統調用而阻塞期間捕捉到一個信號,則該系統調用就被中斷不再繼續執行。
            3,為了幫助應用程序使其不必處理被中斷的系統調用,4.2BSD引入了某些被中斷系統調用的自動重啟動。

            第六節 可重入函數
            1,可重入函數主要用于多任務環境中,一個可重入的函數簡單來說就是可以被中斷的函數,也就是說,可以在這個函數執行的任何時刻中斷它,轉入OS調度下去執行另外一段代碼,而返回控制時不會出現什么錯誤;而不可重入的函數由于使用了一些系統資源,比如全局變量區,中斷向量表等,所以它如果被中斷的話,可能會出現問題,這類函數是不能運行在多任務環境下的。(百度百科)

            第七節 SIGCLD語義
            1,linux平臺上,SIGCLD等價于SIGCHLD。
            2,linux平臺,如果調用signal或者sigset將SIGCHLD的配置設置為忽略,則絕不會產生僵死子進程。
            3,當進程安排捕捉SIGCHLD,并且已經有進程準備好由其父進程等待時,該系統并不調用SIGCHLD信號的處理程序。

            第八節 可靠信號術語和語義
            1,內核在遞送一個原來被阻塞的信號給進程時(而不是在產生該信號時),才決定對它的處理方式。
            2,在信號產生和遞送之間的時間間隔內,稱信號是未決的。
            3,如果在進程解除對某個信號的阻塞之前,這種信號發生了多次,則除非支持POSIX.1實時擴展,否則大多數UNIX并不對信號排隊,代之以UNIX內核只遞送這種信號一次。
            4,POSIX.1并沒有規定當多個信號要遞送給一個進程的時候該如何處理,但POSIX.1的Rationale建議,優先遞送與進程狀態有關的信號。

            第九節 kill和raise函數
            1,kill函數將信號發送給進程或進程組,raise函數則允許進程向自身發送信號。
            2,如果調用kill使其為調用者產生信號,并且如果該信號是不被阻塞的,則在kill返回前該信號或某個未決的非阻塞信號遞送給該進程。

            第十節 alarm和pause函數
            1,如果不忽略或不捕捉SIGALRM信號,則其默認動作是終止調用該alarm函數的進程。
            2,每個進程只能有一個鬧鐘時鐘。
            3,每次調用alarm,均以新參數重新計時,返回上次鬧鐘余值。以0參數調用alarm,則取消鬧鐘并返回鬧鐘余值。
            4,pause函數使調用進程掛起直到捕捉到一個信號。
            5,alarm函數可能引起的問題:
            a,可能擦除前一次的alarm。
            b,修改了對SIGALRM的信號處理配置。
            c,alarm其后的語句執行有競爭條件,期間程序可能掛起,使alarm超時。
            d,可以使用setjmp解決問題c,但是又引入了另一個問題:longjmp可能提前終止其他信號處理程序。
            e,對于自動重啟的低速系統調用,alarm并不起作用。

            第十一節 信號集
            1,信號集:一個表示多個信號的數據類型。
            2,linux信號集sigset_t在<signal.h>如下定義:
            # define _SIGSET_NWORDS (1024 / (8 * sizeof (unsigned long int)))
            typedef struct
              {
                unsigned long int __val[_SIGSET_NWORDS];
              } __sigset_t;
            ...
            typedef __sigset_t sigset_t;
            3,處理信號集的五個函數:
            #include <signal.h>
            int sigemptyset(sigset_t *set);//初始化信號集,清空所有信號 
            int sigfillset(sigset_t *set);//初始化信號集,包含所有信號
            int sigaddset(sigset_t *set,int signo);
            int sigdelset(sigset_t *set,int signo);
            int sigismember(const sigset_t *set,int signo);

            第十二節 sigprocmask函數
            1,信號屏蔽字:當前阻塞而不能遞送給該進程的信號集。(個人理解:當信號產生的時候,不遞送給進程的信號的集合。)
            2,函數sigprocmask可以檢測或(和)更改其信號屏蔽字。

            第十三節 sigpending函數
            1,信號阻塞:信號在當前信號屏蔽字里,則稱該信號是阻塞的。(個人理解)
            2,如果產生了一個被設置為阻塞的信號,則稱該信號是未決的,直到該信號被設置為非阻塞或者忽略。
            3,使用sigprocmask將某些信號設置為非阻塞,則在該函數返回前,至少會有一個信號遞送給進程。
            4,ubuntu11.04沒有對信號進行排隊。
            5,未決信號集(個人概念):使用sigpending獲得的一個信號集,該信號集必定是當前信號屏蔽字的一個子集。該信號集內的信號都必定是已經產生了的。
            5,
            《unix環境高級編程第二版》10.13 sigpending函數:
            有這樣一段描述:
            中文版-在休眠期間如果產生了退出信號,那么此時信號是未決的,但是不再受阻塞,所以在...
            英文版-If we generate the quit signal during this sleep period, the signal is now pending and unblocked, so it is...
            我覺得,這個時候的信號依然是阻塞的!不然,按這樣的描述,書上就有點矛盾了。

            第十四節 sigaction函數
            1,該函數是檢測和修改信號相關聯的處理動作,其標記參數提供了比signal函數更多的選項功能。

            第十五節 sigsetjmp和siglongjmp函數
            1,如果參數savemask非0,則sigsetjmp在env中保存進程的當前信號屏蔽。調用siglongjmp時,如果帶非0savemask的sigsetjmp調用已經保存了env,則siglongjmp從其中恢復保存的信號屏蔽字。
            2,要注意采用保護機制,使得在jmpbuf尚未由sigsetjmp初始化時,調用信號處理程序。

            第十六節 sigsuspend函數
            1,sigsuspend函數在一個原子性操作中,先設置其參數指定的信號屏蔽字,然后使進程休眠。如果捕捉到一個信號(不屬于屏蔽字的)而且從信號處理程序返回,則sigsuspend返回,并將信號屏蔽字恢復為調用sigsuspend之前的值。
            2,如果在等待信號發生的時候希望去休眠,則使用sigsuspend函數是非常適合的。
            3,如果在等待信號期間希望調用其他系統函數,那么在單線程環境下對此問題沒有妥善的解決辦法。(未懂解析原因)

            第十七節 abort函數
            1,POSIX.1說明abort并不理會進程對SIGABRT信號的阻塞和忽略。
            2,如果進程捕捉SIGABRT而且不在信號處理程序中終止自己,POSIX.1聲明當信號處理程序返回的時候,abort終止進程。
            3,POSIX.1要求如果abort調用終止進程,則它對所有打開標準I/O流的效果應當與進程終止前對每個流調用fclose相同。

            第十八節 system函數
            1,POSIX.1要求system忽略SIGINT和SIGQUIT,阻塞SIGCHLD。
            2,因為system執行的命令可能是交互式命令,以及因為system的調用著在程序執行時放棄了控制,等待改執行程序的結束,所以system的調用著就不應當接收這兩個終端產生的信號。
            3,system的返回值是shell的返回值,但是shell的終止狀態并不總是執行命令字符串的終止狀態。
            4,Bourne shell的終止狀態是128加上一個信號編號,該信號終止了正在執行的命令。
            5,僅當shell本身異常終止的時候,system的返回值才報告一個異常終止。
            6,在編寫使用system函數的程序的時候,一定要正確解析返回值。如果直接調用fork,exec和wait,則終止狀態與調用system是不同的。

            第十九節 sleep函數
            1,此函數使調用進程被掛起,直到滿足以下條件之一:
            a,已經過了參數所指定的墻上時鐘時間,返回0。
            b,調用進程捕捉到一個信號并從信號處理程序返回,此時返回未休眠夠的秒數。
            如果alarm信號一樣,由于其他系統活動,實際返回時間比所要求的會遲一些。
            2,FreeBSD 5.2.1,linux 2.4.22和Mac OS X 10.3使用nanosleep提供時間延遲,該函數由Single UNIX Specification的實時擴展說明,它提供的時間延遲是高分辨率的,該函數可以使sleep的實現與信號無關。

            第二十節 作業控制信號
            1,當對一個進程產生四種停止信號(SIGTSTP,SIGSTOP,SIGTTIN或SIGTTOU)中的任意一種時,對同一進程的任一未決SIGCONT信號將被丟棄。與此類似,當對一個進程產生SIGCONT信號時,對同一進程的任一未決停止信號將被丟棄。
            2,如果進程是停止的,SIGCONT的默認動作是繼續運行該進程,否則忽略此信號。通常,對該信號無需做任何事情。當對一個停止的進程產生一個SIGCONT信號時,該進程就繼續運行,即使該信號是被阻塞或忽略的也是如此。

            第二十一節 其他特征
            1,信號名字相關:char *sys_siglist[],void psignal(int signo,const char *msg),char *strsignal(int signo).

            第二十二節 小結


            PS:每天晚上熄燈之后看一點,半個多月的時間終于把這章看完了第一遍。2011-12-4
            久久综合九色综合久99| 成人国内精品久久久久一区| 色婷婷久久久SWAG精品| 无码任你躁久久久久久老妇| 久久精品国产久精国产果冻传媒| 亚洲av伊人久久综合密臀性色| AV无码久久久久不卡网站下载| 99久久国产综合精品网成人影院| 综合久久给合久久狠狠狠97色| 国产99久久久国产精品小说| 久久香蕉一级毛片| 精品国产乱码久久久久久呢| 精品国产婷婷久久久| 亚洲AV日韩AV永久无码久久| 久久人搡人人玩人妻精品首页 | 久久精品中文字幕有码| 性欧美丰满熟妇XXXX性久久久| 久久99中文字幕久久| 久久精品国产99久久久古代| 91麻精品国产91久久久久| 久久久久国产精品人妻| 亚洲中文字幕伊人久久无码| 国产精品美女久久久久网| 久久亚洲国产精品成人AV秋霞 | 久久久久久毛片免费看| 久久精品亚洲中文字幕无码麻豆| 久久综合久久性久99毛片| 国产精品一区二区久久不卡| 久久久久久久免费视频| 久久99精品久久久久久水蜜桃| 九九99精品久久久久久| 国产精品久久久久天天影视| 亚洲日韩中文无码久久| 久久久久亚洲AV无码观看| 亚洲国产日韩综合久久精品| 无码任你躁久久久久久久| 欧美与黑人午夜性猛交久久久| 久久影视国产亚洲| 久久只有这精品99| 久久久久久无码Av成人影院| 精品人妻久久久久久888|