つまり、SIGALRMで応答するシグナルハンドラを定義してもそれが実行できないということです。
これは知らなかったらハマル原因になりますので、気をつけましょう。
Phactoryではがっつり
これはなぜかというと、SIGALRMシグナルはデフォルトではプロセス、スレッドが停止(TERMINATE)するように OSレベルで定義されています。従って、スレッド内で勝手にCGIにSIGALRMを送りつけられると、親スレッドが 当該シグナルを受け取って終了してしまいかねない訳です。このような問題を予め回避するために、Apacheでは SIGALRMシグナルがブロック(マスク)されています。従って、CGIプロセス・スレッドも親Apacheプロセスの マスクを継承し、全体としてSIGALRMがブロックされているという訳です。
Linux系のOSでは、
ですので、CGIでシグナルを用いて非同期処理する際は十分注意が必要です。
シグナルマスクを解除するには、sigprocmaskシステムコールを使用します。
CGIでスクリプト系言語を使用している場合は、上記システムコールを叩くAPIはそれぞれ異なると 思いますので、そこはご自身で調べてみてください。
参考文献
Phactoryではがっつり
ハマリ
ましたが。。。これはなぜかというと、SIGALRMシグナルはデフォルトではプロセス、スレッドが停止(TERMINATE)するように OSレベルで定義されています。従って、スレッド内で勝手にCGIにSIGALRMを送りつけられると、親スレッドが 当該シグナルを受け取って終了してしまいかねない訳です。このような問題を予め回避するために、Apacheでは SIGALRMシグナルがブロック(マスク)されています。従って、CGIプロセス・スレッドも親Apacheプロセスの マスクを継承し、全体としてSIGALRMがブロックされているという訳です。
Linux系のOSでは、
- 親プロセスのシグナルマスク情報が子プロセスに継承される
- シグナルを受信するのは親スレッドだけ
ですので、CGIでシグナルを用いて非同期処理する際は十分注意が必要です。
シグナルマスクを解除するには、sigprocmaskシステムコールを使用します。
CGIでスクリプト系言語を使用している場合は、上記システムコールを叩くAPIはそれぞれ異なると 思いますので、そこはご自身で調べてみてください。
参考文献