青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

Onway

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

APUE第十章 信號 筆記

Posted on 2011-12-04 13:48 Onway 閱讀(437) 評論(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
青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            国产精品久久一区二区三区| 久久久免费精品| 亚洲黄色影院| 宅男精品视频| 欧美丰满高潮xxxx喷水动漫| 国产亚洲二区| 亚洲欧美日韩国产一区二区三区| 免费亚洲网站| 久久激情视频| 黄色成人av在线| 久久九九精品| 久久爱91午夜羞羞| 国内外成人在线视频| 久久久中精品2020中文| 性欧美18~19sex高清播放| 欧美日韩精品免费看| 99re热这里只有精品视频| 欧美黄色日本| 欧美大色视频| 一区二区三区日韩| 一片黄亚洲嫩模| 国产精品美女午夜av| 午夜精品亚洲| 久久精品国产一区二区三区| 在线观看91精品国产麻豆| 裸体丰满少妇做受久久99精品| 久久精彩视频| 欧美国产视频在线观看| 一区免费观看| 久久亚洲精品网站| 久久久无码精品亚洲日韩按摩| 在线不卡中文字幕| 亚洲国产精品一区二区www| 欧美精品入口| 性视频1819p久久| 久久久另类综合| 日韩一区二区精品视频| 亚洲天堂av在线免费观看| 国产精品久久久久久久久久久久久| 性久久久久久久| 久久久91精品国产| 日韩一级精品| 亚洲午夜视频在线| 韩国精品一区二区三区| 亚洲国产婷婷| 国产日韩精品入口| 亚洲国产欧美国产综合一区| 国产精品久线观看视频| 久热爱精品视频线路一| 欧美区在线播放| 久久精品国产免费观看| 欧美激情一二三区| 久久精品视频免费| 欧美精品一区二| 欧美一区二区三区啪啪| 免费观看成人| 亚洲欧美视频在线| 欧美电影免费观看大全| 久久精品亚洲国产奇米99| 欧美日本久久| 亚洲欧美日产图| 久久久7777| 亚洲一区二区三区在线| 久久伊人亚洲| 午夜精品福利一区二区三区av | 亚洲欧美另类综合偷拍| 亚洲第一综合天堂另类专| 亚洲一区二区三区精品视频| 亚洲人成在线观看一区二区| 午夜精品久久久| 在线视频中文亚洲| 欧美高清视频一区二区三区在线观看| 亚洲欧美一区二区精品久久久| 免费亚洲一区二区| 久久综合色天天久久综合图片| 欧美另类一区| 亚洲高清成人| 亚洲高清不卡在线| 久久av免费一区| 久久精品一区二区三区中文字幕 | 国产精品一区三区| 亚洲精品国产品国语在线app| 在线播放日韩| 久久久精品动漫| 久久久亚洲精品一区二区三区| 国产精品一国产精品k频道56| 亚洲美女网站| 一本色道久久综合亚洲精品不卡| 国内一区二区三区在线视频| 国产日韩亚洲欧美综合| 在线一区免费观看| 亚洲香蕉在线观看| 欧美午夜a级限制福利片| 亚洲电影毛片| 最近中文字幕日韩精品 | 9人人澡人人爽人人精品| 亚洲久久在线| 欧美精品在线视频| av不卡在线| 羞羞漫画18久久大片| 国产麻豆成人精品| 久久精品99久久香蕉国产色戒| 久久欧美肥婆一二区| 韩日欧美一区| 欧美a级大片| 亚洲精品久久7777| 亚洲线精品一区二区三区八戒| 欧美日韩一区在线视频| 中文高清一区| 久久国产欧美日韩精品| 国产综合一区二区| 快she精品国产999| 99精品久久免费看蜜臀剧情介绍| 亚洲伊人色欲综合网| 国产精品视频免费一区| 欧美在线观看天堂一区二区三区| 蜜桃av一区| 在线视频精品一区| 国产农村妇女毛片精品久久麻豆 | 亚洲欧美区自拍先锋| 久久亚洲不卡| aa级大片欧美三级| 国产欧美日韩麻豆91| 久久伊人精品天天| 一本久久综合亚洲鲁鲁五月天| 亚洲欧美一区二区三区在线 | 久久综合网色—综合色88| 亚洲国内精品| 国产精品户外野外| 裸体素人女欧美日韩| 99精品热视频只有精品10| 欧美在线视频观看免费网站| 亚洲高清激情| 国产精品青草久久| 玖玖精品视频| 亚洲一区二区在线播放| 亚洲成人在线网| 欧美专区日韩专区| 一区二区三区偷拍| 亚洲福利精品| 国产日韩欧美| 国产精品国产三级国产专播精品人| 久久久久久久一区| 亚洲一区二区三区久久| 91久久精品一区| 麻豆91精品| 久久高清一区| 亚洲综合首页| 日韩午夜在线观看视频| 狠狠噜噜久久| 国产亚洲精品v| 欧美午夜宅男影院在线观看| 狂野欧美一区| 99这里只有久久精品视频| 久久免费精品日本久久中文字幕| 一本一本久久a久久精品综合麻豆| 国产综合一区二区| 国产午夜精品久久久久久久| 欧美午夜精品久久久久久孕妇| 免费高清在线一区| 久久免费99精品久久久久久| 欧美亚洲一区在线| 性色av一区二区三区| 亚洲一区精品在线| 亚洲午夜电影| 亚洲一区二区三区四区在线观看| 日韩视频不卡中文| 亚洲狼人精品一区二区三区| 亚洲高清不卡在线观看| 欧美顶级大胆免费视频| 欧美成人高清视频| 欧美激情视频在线免费观看 欧美视频免费一 | 99re视频这里只有精品| 亚洲日本va午夜在线电影| 亚洲第一精品在线| 亚洲国产日本| 亚洲精品国产精品久久清纯直播| 亚洲二区在线视频| 亚洲精品视频免费| 一本色道久久综合亚洲精品不| 日韩视频在线观看国产| 一区二区激情| 亚洲欧美日韩直播| 久久av在线| 久热这里只精品99re8久| 欧美~级网站不卡| 亚洲国产婷婷香蕉久久久久久99| 亚洲国内自拍| 在线一区二区三区四区五区| 亚洲综合二区| 久久久久久久综合| 欧美激情一区二区三区高清视频 | 欧美福利影院| 欧美涩涩网站| 国产日韩精品视频一区| 亚洲电影第1页| 一区二区三区四区国产精品| 亚洲欧美日韩成人| 老鸭窝91久久精品色噜噜导演| 欧美mv日韩mv亚洲|