應(yīng)用程序信號(hào)太多，會(huì)導(dǎo)致什么問(wèn)題？

dingyujie

有個(gè)服務(wù)器的程序，進(jìn)程之間需要很頻繁的互發(fā)信號(hào)，來(lái)完成一些處理，這樣會(huì)對(duì)系統(tǒng)產(chǎn)生怎樣的影響？另外一個(gè)問(wèn)題就是，信號(hào)處理函數(shù)中有很多邏輯，比如需要通過(guò)socket發(fā)送數(shù)據(jù)之類的，這樣有什么不妥嗎？

先謝過(guò)大牛了。

dingyujie

回復(fù) 2# stephen_du


    嗯。有其他的方案，不過(guò)我主要是想搞清楚，這么做會(huì)有哪些直接或者明顯的影響。

灌水菜鳥(niǎo)

建議看看信號(hào)的實(shí)現(xiàn)機(jī)制，通常處理一個(gè)信號(hào)是需要反復(fù)進(jìn)出內(nèi)核的。至于有什么樣的影響，甚至量化的數(shù)據(jù)，就跟你的實(shí)際用例和環(huán)境緊密相關(guān)了，不妨寫個(gè)驗(yàn)證用例試試先。

cuibixiong_cu

我的想法，signal是linux中IPC通信的一種方式，處理的時(shí)間一般是中斷，異常，系統(tǒng)調(diào)用，這樣的話就會(huì)有一種問(wèn)題，當(dāng)一個(gè)A Process向B Process發(fā)送signal的時(shí)候，其實(shí)只是在B process的task_struct中進(jìn)行了標(biāo)記，而沒(méi)有立即調(diào)用這個(gè)signal的handler，B Process調(diào)用signal handler的時(shí)機(jī)是當(dāng)處理中斷，異常，系統(tǒng)調(diào)用完成之后，會(huì)check signal，可以參考arch/arm/kernel/entry-common.S的func work_pending。

如果你的處理必須是實(shí)時(shí)的話，那么用signal就不是很好了，signal常用的地方還是處理一下異常情況，并不適用于進(jìn)程間數(shù)據(jù)通信

dingyujie

回復(fù) 5# cuibixiong_cu


    也不是嚴(yán)格意識(shí)上的要求實(shí)時(shí)，但至少應(yīng)該比進(jìn)程在那空轉(zhuǎn)輪詢狀態(tài)好些吧，因?yàn)榈却龑?shí)在太耗性能。。。

灌水菜鳥(niǎo)

回復(fù) 6# dingyujie


    兄弟，你說(shuō)的這種情況，應(yīng)該是“同步“。百度一下吧。

鳥(niǎo)菜小

要看怎么實(shí)現(xiàn)的，其實(shí)要正確的寫好信號(hào)處理函數(shù)不容易，要考慮如下幾點(diǎn)：

1，信號(hào)處理的方式，是異步處理，還是定向到特定的線程去做同步處理。

2，如果是異步處理，安全性即可重入問(wèn)題尤其重要，不可重入的函數(shù)，甚至errno都會(huì)受影響，代碼謹(jǐn)慎。

3，使用什么類型的信號(hào)，是否可靠是否會(huì)排隊(duì)，決定了你的處理邏輯。

linux_c_py_php

進(jìn)程間通信方法很多, 簡(jiǎn)單的內(nèi)存共享隊(duì)列, 進(jìn)程共享互斥鎖+條件變量, 信號(hào)量, 都能解決空轉(zhuǎn)問(wèn)題,

dingyujie

回復(fù) 9# linux_c_py_php


    嗯，我是想問(wèn)，如果就是用信號(hào)，會(huì)導(dǎo)致什么具體的問(wèn)題和影響？