2011-04-12 103 views
0

我們在Linux中使用C語言。有沒有可能以某種意想不到的方式運行函數,尤其是當我們處理信號時?系統功能瑕疵

我們發現有時,system()函數會阻止執行,或者它會拋出SIGSEGV

e.g:

system ("/bin/mv a b"); 

是否有使用system()任何已知的缺陷,會解釋一下嗎?

+5

'system()* * always * blocks直到命令完成。 – 2011-04-12 05:51:24

+0

但mv命令不需要太多時間,對吧? – abubacker 2011-04-12 05:58:22

+2

它取決於:如果您要移動來自不同分區的大文件,可能需要一些時間才能完成 – Heisenbug 2011-04-12 05:59:39

回答

2

system()功能做它應該做得很好。只要調用正確,行爲就非常可靠。它有兩種操作模式:

  1. 檢查是否有命令解釋器可用 - 當參數是空指針時。
  2. 運行給定的命令,等待命令在返回前完成。

因此,system()語句阻塞,直到運行命令的shell完成。在類Unix系統上,調用的命令是有效的:

"sh", "-c", "...argument to system...", NULL 

這意味着傳遞的字符串由shell解釋。需要多長時間取決於執行的命令。如果你需要,你可以考慮使用shell符號來在後臺運行命令:

system("(/bin/mv a b &)"); 

在有些情況下system()本身會產生SIGSEGV少數情況。你將不得不通過它一個無效的指針,指向程序中無效的地方。

0

system()調用supposed to block直到執行完成。如果需要一個小時將a移動到b,則過程或線程調用system()塊阻塞一個小時。瞭解這一點,可以解釋奇怪的行爲。

如果您期望system()立即返回,則可能意味着您希望調用它之後運行的代碼在您看到奇怪行爲時輸入。由於system()花費的時間比預期的要長,很可能某些內存區域未被分配或初始化。當另一個線程或進程試圖訪問它時,這可能是分段錯誤的原因。

換句話說,如果你沒有期望system()來阻止,你可能認爲它後面的代碼會比實際運行得更快。

揭穿這將是另一個問題的主題。這個答案不是,你沒有看到system()函數中的缺陷,它的行爲完全如預期。

+0

http://stackoverflow.com/questions/3838565/replace-system-with-non-blocking-function – 2011-04-12 06:04:20

+1

@Michael - 我認爲OP看到的SEGV是(可能)由於系統()之後的代碼不是達到了預期的時間,因爲OP沒有想到會阻止它。我更新了我的答案。由於OP傳遞一個字符串作爲參數,這似乎是一個可能的解釋。 – 2011-04-12 06:42:34