• <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>
            posts - 200, comments - 8, trackbacks - 0, articles - 0
                     轉(zhuǎn)載請(qǐng)注明 出自:http://m.shnenglu.com/mysileng/archive/2013/01/11/197202.html

                 討論兩個(gè)由sigchld信號(hào)引起的血案問(wèn)題,討論的環(huán)境是服務(wù)端的并發(fā)程序。我們先把最原始的服務(wù)器端并發(fā)程序模型貼出來(lái):

                 以上是服務(wù)器端程序,我們先不看被注視掉的部分,程序?qū)τ诿恳粋€(gè)accept的TCP連接會(huì)產(chǎn)生一個(gè)子進(jìn)程,交給子進(jìn)程去處理。而子進(jìn)程其實(shí)并不做什么,直接睡眠3秒就結(jié)束。可以想象這樣當(dāng)子進(jìn)程exit以后,會(huì)給父進(jìn)程發(fā)sigchld信號(hào),通知父進(jìn)程自己掛了。但是在我們的父進(jìn)程中,我們對(duì)于sigchld信號(hào)采用默認(rèn)處置(忽略)。結(jié)果可想而知就是來(lái)一個(gè)連接,就產(chǎn)生一個(gè)僵死進(jìn)程。我們運(yùn)行程序3次,看看是否會(huì)得到3個(gè)僵死進(jìn)程。
            服務(wù)器端運(yùn)行程序,被某客戶端連接3次:

            客戶端運(yùn)行程序執(zhí)行3次,并查看進(jìn)程情況:

                首先聲明,我們用客戶端可以查看服務(wù)器端進(jìn)程的原因是,我們把客戶端和服務(wù)端放在了一臺(tái)電腦上進(jìn)程本次試驗(yàn)。我們并不關(guān)心cli客戶端的具體實(shí)現(xiàn),因?yàn)榉?wù)器并不從客戶端獲取任何信息。
                從結(jié)果可知,果然服務(wù)端果斷產(chǎn)生了3個(gè)僵死進(jìn)程。接下來(lái)我們加上對(duì)sigchld的處理程序。但加上以后也將產(chǎn)生我們的第一個(gè)血案:

            白色為客戶端,黑為服務(wù)端:

                可見(jiàn),僵死進(jìn)程的問(wèn)題已經(jīng)解決,但還有個(gè)潛在的隱藏危機(jī)。
                PHOSIX對(duì)于向accept這種慢速的系統(tǒng)系統(tǒng)調(diào)用有一個(gè)基本規(guī)則(apue,unp都有涉及):當(dāng)進(jìn)程阻塞于某個(gè)慢系統(tǒng)調(diào)用的時(shí)候(我們的程序是accept),當(dāng)進(jìn)程捕捉到某個(gè)信號(hào)(我們的程序是sigchld),并從信號(hào)的處理函數(shù)返回時(shí)(我的程序是deal函數(shù)),進(jìn)程不再阻塞與之前的慢速系統(tǒng)調(diào)用,而是返回一個(gè)EINTER錯(cuò)誤。
                 對(duì)于上面的這個(gè)規(guī)則,各個(gè)操作系統(tǒng)的對(duì)待方式是不同的。有的操作系統(tǒng)返回EINTER以后,就會(huì)自動(dòng)重啟之前的慢速系統(tǒng)調(diào)用而繼續(xù),有些則不會(huì)自動(dòng)重啟。對(duì)我們實(shí)驗(yàn)程序的這個(gè)操作系統(tǒng)環(huán)境(centos5.5),從結(jié)果來(lái)看,因?yàn)椴](méi)打印"accept error"并退出程序,我猜想,centos5.5應(yīng)該是會(huì)自動(dòng)重啟慢速系統(tǒng)調(diào)用的。也就是說(shuō)在這里我因?yàn)椴僮飨到y(tǒng)的優(yōu)秀,躲過(guò)一劫(躲過(guò)第一次血案)。但為了可移植性我們應(yīng)該改進(jìn)程序?yàn)橐韵聦?shí)現(xiàn):

                我的改動(dòng)主要集中在對(duì)accpt的錯(cuò)誤處理里面。接下來(lái)闡述另外一個(gè)血案
            ----------------------------------------------------------------------------
                我們繼續(xù)沿用上述的最后一次服務(wù)端程序來(lái)進(jìn)行接下來(lái)的實(shí)驗(yàn),現(xiàn)在我們編寫(xiě)一個(gè)客戶端程序,客戶端一次性跟服務(wù)端申請(qǐng)5個(gè)連接。客戶端的程序如下:

               整個(gè)程序的構(gòu)架大概如下:

                這里客戶端最需要注意的是程序的最后一句并不是一個(gè)個(gè)close所有的套接字描述符,而是調(diào)用exit程序結(jié)束進(jìn)程。根據(jù)APUE描述,exit系統(tǒng)調(diào)用會(huì)執(zhí)行關(guān)閉該進(jìn)程所有描述符的操作,也就是說(shuō)客戶端的所有描述符,包括套接字描述符也被幾乎同時(shí)關(guān)閉了。也就是說(shuō)服務(wù)端的由監(jiān)聽(tīng)進(jìn)程產(chǎn)生的所有處理子進(jìn)程也會(huì)在幾乎同時(shí)死掉。那么就會(huì)在幾乎同時(shí)給父進(jìn)程發(fā)送sigchld信號(hào)。情況如下:

                血案即將發(fā)生。請(qǐng)注意,根據(jù)APUE對(duì)于信號(hào)在1-31之內(nèi)的的信號(hào),因?yàn)闅v史原因,是不可靠信號(hào),也就說(shuō),SIGCHLD信號(hào)在被遞送到正在阻塞SIGCHLD信號(hào)的進(jìn)程時(shí),是不會(huì)排隊(duì)的,而是會(huì)被系統(tǒng)壓縮。上述問(wèn)題就是當(dāng)5個(gè)sigchld信號(hào)幾乎同時(shí)到達(dá)父進(jìn)程時(shí),只有第一個(gè)能順利被父進(jìn)程的信號(hào)處理函數(shù)處理。又因?yàn)楸籹ignal/sigaction設(shè)置的信號(hào)處理函數(shù)會(huì)自動(dòng)阻塞正在處理的信號(hào)這一原則,接下來(lái)沒(méi)被處理的4個(gè)sigchld信號(hào),被排在了父進(jìn)程門(mén)口。不巧的是,sigchld又是不可靠信號(hào),結(jié)果是4個(gè)sigchld被壓縮成一個(gè)sigchld信號(hào)。這就導(dǎo)致信號(hào)的丟失。也因?yàn)閬G失了3個(gè)sigchld信號(hào),就會(huì)產(chǎn)生3個(gè)僵尸進(jìn)程。你說(shuō)這是不是一個(gè)名符其實(shí)的血案。接下來(lái)我們實(shí)驗(yàn)一下:

                可以清晰的看到結(jié)果如預(yù)期,所有出現(xiàn)信號(hào)丟失導(dǎo)致3個(gè)僵死進(jìn)程。那么怎么解決這個(gè)問(wèn)題呢?~。。。。

            Feedback

            # re: 進(jìn)程并發(fā)服務(wù)器中,sigchld信號(hào)引發(fā)的血案?(原)  回復(fù)  更多評(píng)論   

            2014-09-24 14:26 by anonymous
            又因?yàn)楸籹ignal/sigaction設(shè)置的信號(hào)處理函數(shù)會(huì)自動(dòng)阻塞正在處理的信號(hào)這一原則,接下來(lái)沒(méi)被處理的4個(gè)sigchld信號(hào),被排在了父進(jìn)程門(mén)口。不巧的是,sigchld又是不可靠信號(hào),結(jié)果是4個(gè)sigchld被壓縮成一個(gè)sigchld信號(hào)。

            所謂的信號(hào),只是一個(gè)bitmap,你同時(shí)發(fā)4個(gè)sigchld,每次sigchld對(duì)應(yīng)的bit都會(huì)被置位,但是是同一個(gè)bit,下一輪sig handler處理的時(shí)候只會(huì)當(dāng)成一個(gè)signal來(lái)處理。
            久久综合九色综合精品| 久久综合视频网| 国产精自产拍久久久久久蜜| 久久久久一本毛久久久| 久久精品中文字幕一区| 丁香五月网久久综合| 理论片午午伦夜理片久久| 久久精品亚洲AV久久久无码| 久久er热视频在这里精品| 久久一区二区免费播放| 久久99精品久久久久子伦| 久久久久国产视频电影| 99久久99久久精品免费看蜜桃| 91久久香蕉国产熟女线看| 久久综合九色综合网站| 久久久久国色AV免费看图片| 国产亚洲欧美成人久久片| 国产精品99久久久精品无码| 久久久久人妻精品一区三寸蜜桃| 蜜臀av性久久久久蜜臀aⅴ| 香港aa三级久久三级老师2021国产三级精品三级在 | 久久精品九九亚洲精品| 亚洲国产精品无码久久九九 | 欧美综合天天夜夜久久| 亚洲AV无码1区2区久久| 国内精品久久久久影院老司| 久久精品女人天堂AV麻| 久久久久国产精品| 国产精品久久久久9999高清| 久久99精品久久久久久久久久 | 久久99久久99小草精品免视看| 久久热这里只有精品在线观看| 青青草国产97免久久费观看| 久久99精品久久久久久9蜜桃| 69SEX久久精品国产麻豆| 国产精品久久久久久| 久久九九青青国产精品| 亚洲国产精品久久| 大蕉久久伊人中文字幕| 岛国搬运www久久| 国产成人综合久久精品红|