SIGWAITINFO

Section: Linux Programmer's Manual (2)
Updated: 2017-09-15
IndexJM Home Page
 

名前

sigwaitinfo, sigtimedwait, rt_sigtimedwait - キューに入れられたシグナルを同期して待つ 

書式

#include <signal.h>int sigwaitinfo(const sigset_t *set, siginfo_t *info);int sigtimedwait(const sigset_t *set, siginfo_t *info, const struct timespec *timeout);

glibc 向けの機能検査マクロの要件 (feature_test_macros(7) 参照):

sigwaitinfo(), sigtimedwait(): _POSIX_C_SOURCE >= 199309L 

説明

sigwaitinfo() は set のうちのどれかのシグナルが処理待ちになるまで、 呼び出しスレッドの実行を一時停止する (呼び出しスレッドに対して set のうちのどれかのシグナルが既に待機中 (pending) である場合、 sigwaitinfo() はすぐに戻る)。

sigwaitinfo() はそのシグナルを待機中のシグナルの集合から削除し、関数の結果としてシグナル番号を返す。 info 引き数が NULL でない場合、配送されたシグナルの情報が入った siginfo_t 型 (sigaction(2) を参照) の構造体をinfo が指すバッファーに入れて返す。

呼び出し元に対して set の複数のシグナルが処理待ちの場合、 sigwaitinfo() で取得するシグナルは通常の順序決定ルールに基づいて決定される。 詳細は signal(7) を参照のこと。

sigtimedwait() は、 sigwaitinfo() と次の点を除いて全く同じように動作する。この関数にはもう 1 つの引き数timeoutがあり、シグナル待ちでスレッドが一時停止する時間を指定することができる(この時間はシステムクロックの粒度に切り上げられ、カーネルのスケジューリング遅延により少しだけ長くなる可能性がある)。この引き数の型は以下のとおりである:

struct timespec {
    long    tv_sec;         
    long    tv_nsec;         }

この構造体の 2 つのフィールドがともに 0 の場合、ポーリングが行われる: sigtimedwait() は、呼び出し側プロセスに対して 待機しているシグナルの情報を返して戻るか、 set のうちのどのシグナルも待機していない場合はエラーを返して戻る。 

返り値

成功した場合、 sigwaitinfo() と sigtimedwait() はシグナル番号 (すなわち 0 より大きい数) を返す。 失敗した場合、2 つの関数は -1 を返し、 errno はエラーを表す値に設定される。 

エラー

EAGAIN
set のうちのどのシグナルも sigtimedwait() に指定された timeout の期間内に処理待ちにならなかった。
EINTR
シグナル待ちがシグナルハンドラーによって中断 (interrupt) された (このハンドラーは set にあるシグナル以外のものである)。signal(7) 参照。
EINVAL
timeout が不正である。
 

準拠

POSIX.1-2001, POSIX.1-2008. 

注意

通常の使用法では、呼び出し側プロセスはこれらの関数より先に sigprocmask(2) の呼び出すことにより setに含まれるシグナルをブロックし (そのためにこれらのシグナルがこの後に続く sigwaitinfo() や sigtimedwait() の呼び出しの間に処理待ちになった場合には、デフォルトの動作は行われず)、 これらのシグナルに対するハンドラーは設定しない。 マルチスレッドプログラムでは、 sigwaitinfo() や sigtimedwait() を呼び出したスレッド以外のスレッドで、そのシグナルがデフォルトの動作に基いて処理されないように、全てのスレッドで該当シグナルをブロックすべきである。

指定されたスレッドに対する処理待ちのシグナルの集合は、 そのスレッド自体宛ての処理待ちのシグナル集合と、プロセス全体宛ての 処理待ちのシグナル集合をあわせたものである (signal(7) 参照)。

SIGKILLSIGSTOP を待とうとした場合、黙って無視される。

一つのプロセス内の複数のスレッドが sigwaitinfo() や sigtimedwait() で同じシグナルを待って停止した場合、 プロセス全体宛てのシグナルが処理待ちになると、複数のスレッドのうち一つだけが 実際にそのシグナルを受信することになる。 どのスレッドがシグナルを受信するかは決まっていない。

sigwaitinfo() or sigtimedwait(), can't be used to receive signals that are synchronously generated, such as the SIGSEGV signal that results from accessing an invalid memory address or the SIGFPE signal that results from an arithmetic error. Such signals can be caught only via signal handler.

POSIX では sigtimedwait() の引き数 timeout の値を NULL にした場合の意味を未定義としている。sigwaitinfo() を呼び出したのと同じ意味としてもよいことになっており、 実際 Linux ではこのように動作する。 

C ライブラリとカーネルの違い

Linux では、 sigwaitinfo() は sigtimedwait() を用いて実装されたライブラリ関数である。

The glibc wrapper functions for sigwaitinfo() and sigtimedwait() silently ignore attempts to wait for the two real-time signals that are used internally by the NPTL threading implementation. See nptl(7) for details.

The original Linux system call was named sigtimedwait(). However, with the addition of real-time signals in Linux 2.2, the fixed-size, 32-bitsigset_t type supported by that system call was no longer fit for purpose. Consequently, a new system call, rt_sigtimedwait(), was added to support an enlarged sigset_t type. The new system call takes a fourth argument, size_t sigsetsize, which specifies the size in bytes of the signal set in set. This argument is currently required to have the valuesizeof(sigset_t) (or the error EINVAL results). The glibcsigtimedwait() wrapper function hides these details from us, transparently calling rt_sigtimedwait() when the kernel provides it. 

関連項目

kill(2), sigaction(2), signal(2), signalfd(2), sigpending(2),sigprocmask(2), sigqueue(3), sigsetops(3), sigwait(3),signal(7), time(7) 

この文書について

この man ページは Linux man-pages プロジェクトのリリース 5.10 の一部である。プロジェクトの説明とバグ報告に関する情報はhttps://www.kernel.org/doc/man-pages/ に書かれている。


関連キーワード

シグナル,sigtimedwait,sigwaitinfo,SIGWAITINFO,呼び出し,プロセス,that,timeout,エラー,call 

Index

名前
書式
説明
返り値
エラー
準拠
注意
C ライブラリとカーネルの違い
関連項目
この文書について

This document was created byman2html, using the manual pages.
Time: 15:49:13 GMT, July 11, 2021