[再版]解決策：signal_pendingおよびreturn-ERESTARTSYS

 

多くの場合、そのような例はスリープのコードに表示されます。

    if（signal_pending（current））{

     ret = -ERESTARTSYS ;

     右に戻る;

    }

    - ERESTARTSYS  この平均値を何最後に？ 

 

     -ERESTARTSYSは、シグナル関数が処理された後、シグナル関数が再実行される前に特定のシステムコールが実行されることを示します。

つまり、シグナル関数の前にシステムコールがある場合、ユーザーシグナル関数をスケジュールする前に、カーネルはシステムコールの戻り値をチェックして、このシグナルが原因でシステムコールが中断されたかどうかを確認します。戻り値が-ERESTARTSYSの場合、現在のスケジュールされたシグナルには-ERESTARTSYS属性があり、システムはユーザーシグナル関数が戻った後にシステムコールを実行します

 

    このプロセスは、掘り下げる必要はなく、上位ライブラリ関数を知っています。Linuxの場合、 -ERESTARTSYS の戻り値を受け取ると、自動的にこの呼び出しが再度呼び出されます。

に関しては

signal_pending （current）--- "現在のプロセスにシグナル処理があるかどうかを確認します。0以外を返すと、処理するシグナルがあることを意味します。

シナリオ分析：
1.システムコールが入力バッファーが空にならないなどの待機状態にある場合、この時点でシグナルが生成されます。このシグナルは、「シグナリング」と呼ばれるプロセスのthread_info構造でのみ識別されます、次にプロセスのシステムコールをウェイクアップします。システムコールがウェイクアップした後は、signal_pending（）のみを使用してシグナルがあるかどうかを確認します。ここでは、シグナルは処理されません。この時点でシグナルがある場合、システムコールはERESTARTSYSを返します。ユーザー空間に戻ると、対応する信号処理関数がthread_infoの信号識別ビットに従って呼び出されます。これは、いわゆる「受信信号」です。Linuxの場合、上位ライブラリ関数は、システムコールERESTARTSYSの戻り値に従ってシステムコールを再起動し、 Solarisの場合システムコールが失敗します。Linuxでは、再起動されたシステムコールによってバッファが再度チェックされ、バッファが空になります。これは、現在のシグナルが、バッファにデータがあることを示すシグナルではないことを示し、待機し続け、今すぐプロセスを繰り返します。データを直接処理することができ、システムコールが終了すると、通常は
注意してください：「シグナル」唯一のアイデンティティthread_infoは、ちょうど、目を覚ますために信号システムコールをチェック）（signal_pending任意の信号識別があれば、裁判官が見たときに、そのようなすべてのように、中thread_infoシステムコールから返された、または例外ハンドラが戻る「信号を受け入れることが」真のクロック割り込み処理関数が戻ったら、thread_infoでどの信号を確認し、対応する処理プログラムを呼び出して
補足します。Solarisの場合、上記の状況では、読み取りが待機していて、バッファーがいっぱいで、ここで説明しているのとは異なり、読み取りプロセスをウェイクアップします。信号 "

プロセスpに保留中のシグナルがあるかどうかを確認します（p-> thread_info->フラグのTIF_SIGPENDINGビットが設定されているかどうか）
--------------------------- --------------------------
static inline int signal_pending （struct task_struct * p）
{
    ありそうにない（test_tsk_thread_flag（p、TIF_SIGPENDING））;
}

転送元：解決策：signal_pendingおよびreturn-ERESTARTSYS