Armadilloフォーラム

竹之下です。

> その際、子プロセスが終了してゾンビ化しないようにシグナルを受信するように関数登録していますが
> この関数内ではファイルのRead／Writeとかprintfとかを実施すべきではないのでしょうか？
C言語でプログラムを記述しているという前提で考えた場合、シグナルハンドラの中ではprintfは実施すべきではないですね。

かなり昔の記事ですが、下記のブログが参考になると思います。
「なんでシグナルハンドラ内でprintfを読んではダメなのか？」についても記載があります。
UNIX上でのC++ソフトウェア設計の定石 (2) - memologue : http://d.hatena.ne.jp/yupo5656/20040712/p2
シグナルハンドラを使わないでシグナルをハンドルする - memologue : http://d.hatena.ne.jp/yupo5656/20060114/p1

参考になれば。

KES)小西です。

２つ問題があると思います。
printfは竹之下さんがおっしゃっているようにprintfは
async-signal-safe functionsではないため、保障外となります。
(http://linuxjm.osdn.jp/html/LDP_man-pages/man7/signal.7.html
でのasync-signal-safe functionsのリストが保障対象となります。実装されてないものがあったり。。。)

でファイルのアクセスは
http://linuxjm.osdn.jp/html/LDP_man-pages/man2/write.2.html
でのバグ報告より、3.13以前ではファイルオフセットの更新に関してはアトミック性が死んでいるため
メインのスレッドとシグナルハンドラで同時にアクセスすると
ファイルが壊れる可能性があるかと思います。
↑これが「デッドロック」ってことはないでしょうか？
もっとも、メインでオープンしたディスクリプタをシグナルハンドラからグローバルアクセスした場合になりますが。。。

伊澤です。
こう言う話になるとしゃしゃり出ます。

> 子プロセス(fork)のsystem命令でNtpClientを実行して時刻合わせをしています。
まず確認ですが、非同期にNtpClientを実行したいだけでしょうか。
もしそうであるなら、fork()せずにsystem()にアンパサンド(&)つきの引き数を渡せばいいような気がします。
system()はシェルを起動しますので、シェルが良きに計らってくれます。
NtpClientは使ったことがありませんが、system("ntpclient -h ... -s &")のような感じでしょうか。

> その際、子プロセスが終了してゾンビ化しないようにシグナルを受信するように関数登録していますが
そうではなくて、敢えてfork&execイディオムで起動するということでしょうか。
その場合も、通常はwaitで死に水を取れば充分な気がします。
int pid = fork()したならwaitpid(pid, & status, 0)で終了までブロックしますが、
定期的に通過するポイントでwaitpid(pid, & status, WNOHANG)でしょうか。
本件ではNtpClientの再起動をするわけでもないでしょうから、signalは見なくてよさそうかと。
signal処理しなければ、printf()などの問題も杞憂ですね。