Provided by: manpages-ja-dev_0.5.0.0.20180315+dfsg-1_all ![bug](/img/bug.png)
![bug](/img/bug.png)
名前
getcontext, setcontext - ユーザーコンテキストを取得/設定する
書式
#include <ucontext.h> int getcontext(ucontext_t *ucp); int setcontext(const ucontext_t *ucp);
説明
System V 的な環境では、 mcontext_t および ucontext_t という 2 つの型と、 getcontext(), setcontext(), makecontext(3), swapcontext(3) という 4 つの関数が <ucontext.h> で定義されており、あるプロセス内部で制御 下にある複数のスレッド間で、 ユーザーレベルのコンテキスト切替えができるようになっている。 mcontext_t 型はマシン依存で、外部からは隠蔽されている。 ucontext_t 型は構造体で、少なくとも以下の 4 つの フィールドを持つ。 typedef struct ucontext { struct ucontext *uc_link; sigset_t uc_sigmask; stack_t uc_stack; mcontext_t uc_mcontext; ... } ucontext_t; sigset_t と stack_t は <signal.h> で定義されている。 ここで uc_link は、 現在のコンテキストが終了したと き、 続いて切り替わるコンテキストへのポインターである (現在のコンテキストが makecontext(3) で生成されたも のの場合)。 uc_sigmask はこのコンテキストでブロックされている シグナル群である (sigprocmask(2) を見よ)。 uc_stack はこのコンテキストが用いているスタックである (signalstack(2) を見よ)。 uc_mcontext は保存されて いるコンテキストの マシン特有の表現形式であり、 ここには呼び出したスレッドのマシンレジスターが格納され る。 getcontext() 関数は、 ポインター ucp が指す構造体を、 現在アクティブなコンテキストに初期化する。 setcontext() 関数は、ポインター ucp が指すユーザーコンテキストをリストアする。 呼び出しに成功すると返ら ない。 このコンテキストは、以前に getcontext() または makecontext(3) で得られたものか、 あるいはシグナ ルの第三引数として与えられたものになる。 コンテキストが getcontext() の呼び出しによって得られていたものの場合は、 プログラムはこの呼び出しから 返った直後からのように実行を継続する。 コンテキストが makecontext(3) の呼び出しによって得られていたものの場合は、 プログラムの実行はその makecontext(3) 呼び出しの第二引数で指定された関数 func を呼び出すかたちで継続する。 func から返ると、 makecontext(3) 呼び出しの第一引数で指定されていた ucp 構造体の uc_link メンバで継続する。 このメンバが NULL だった場合は、そのスレッドは終了する。 コンテキストがシグナルハンドラーの呼び出しによって得られていたものの場合は、 古い標準によれば 「プログラ ムの実行はシグナルによって割り込まれた命令の次の命令から継続される」。 しかしこの文は SUSv2 で削除された ので、 現在の判断は「結果は定義されていない」である。
返り値
成功すると、 getcontext() は 0 を返し、 setcontext() は返らない。 失敗すると、両者とも -1 を返し、errno をエラーに応じて設定する。
エラー
定義されていない。
属性
マルチスレッディング (pthreads(7) 参照) 関数 getcontext() と setcontext() はスレッドセーフである。
準拠
SUSv2, POSIX.1-2001. POSIX.1-2008 では、移植性の問題から getcontext() の仕様が削除された。 代わりに、ア プリケーションを POSIX スレッドを使って書き直すことが 推奨されている。
注意
このメカニズムの最古の実装は、 setjmp(3)/longjmp(3) 機構であった。 これらにはシグナルコンテキストの取り 扱いが定義されていなかったので、 次の段階では sigsetjmp(3)/siglongjmp(3) のペアが現われた。 現在の機構で はずっと細かな制御ができる。 一方 getcontext() から返ったとき、 これが最初の呼び出しであったか、 それと も setcontext() 呼び出しからのものであるかを 区別する容易な方法がなくなってしまった。 ユーザーは「しお り」機構を自分で作らなければならない。 レジスター変数は (レジスターはリストアされてしまうので) これをやっ てくれない。 シグナルが発生すると、 現在のユーザーコンテキストは保存され、 シグナルハンドラー用のコンテキストがカーネ ルによって生成される。 今後はハンドラーに longjmp(3) を使わせないこと: この関数のコンテキスト下での動作 は定義されていない。 代わりに siglongjmp(3) か setcontext() を使うこと。
関連項目
sigaction(2), sigaltstack(2), sigprocmask(2), longjmp(3), makecontext(3), sigsetjmp(3)
この文書について
この man ページは Linux man-pages プロジェクトのリリース 3.79 の一部 である。プロジェクトの説明とバグ報告 に関する情報は http://www.kernel.org/doc/man-pages/ に書かれている。