linux手册翻译——getcontext(2) setcontext(2)

getcontext, setcontext - get or set the user context

       #include 

       int getcontext(ucontext_t *ucp);
       int setcontext(const ucontext_t *ucp);

在类System V的系统中，在中定义了两种数据类型：mcontext_t ，ucontext_t 以及四个函数：getcontext()， setcontext()， makecontext(3)，swapcontext(3) 以实现用户级线程在其控制进程中进行上下文切换。mcontext_t 类型依赖于CPU硬件且不透明，ucontext_t 类型是一个至少具有以下字段的结构，详见：ucontext(3)：

typedef struct ucontext_t {
           struct ucontext_t *uc_link;
           sigset_t          uc_sigmask;
           stack_t           uc_stack;
           mcontext_t        uc_mcontext;
           ...
} ucontext_t;

sigset_t、stack_t 定义在中.
uc_link ，指向当前上下文终止时将恢复的上下文;
uc_sigmask，信号的阻塞掩码；
uc_stack，上下文使用的堆栈，见sigaltstack(2)
uc_mcontext，用于保存的上下文的特定表示特定于机器的信息(machine-specific representation)，如寄存器信息，mcontext_t是不透明的。

getcontext()，将当前活动的上下文初始化到参数ucp指向的结构中。
setcontext()，恢复到ucp 指向的用户上下文（即开始执行执行的上下文）， 成功调用不会返回。上下文应该是通过调用 getcontext() 或 makecontext(3) 创建的，或者信号处理程序的第三个参数(见sigaction)。

如果上下文是通过getcontext()获得的，则在调用setcontext()后，将从getcontext()的调用点之后继续执行，就好像从getcontext()调用返回一样。
如果上下文是通过makecontext() 获得的，则在调用setcontext()后，将调用func函数，即makecontext(3) 的第二个参数。 当函数 func 返回时，将切换到 uc_link 指向的执行上下文，即 makecontext(3) 第一个参数，若uc_link为 NULL ，则线程退出。
如果上下文是通过调用信号处理程序获得的，在旧的标准中指示为“程序执行继续执行被信号中断的指令之后的程序指令”。 但是这句话在 SUSv2 中被去掉了，现在的是“结果未定”。

成功时，getcontext() 返回 0，而 setcontext() 不返回。 出错时，两者都返回 -1 并适当设置 errno。

未定义。

Interface	Attribute	Value
getcontext(), setcontext()	Thread safety	MT-Safe race:ucp

类似的机制，最早的是setjmp(3)/longjmp(3)，此机制没有保存有关信号信息(即信号掩码)，sigsetjmp(3)/siglongjmp(3) 新增了对信号掩码的改进，即可以保存和恢复信号掩码。 当前的ucontext机制提供了更多的控制。 但是，目前还没有简单的方法来检测 getcontext() 的返回是来自第一次调用还是通过 setcontext() 调用。 用户必须发明他们自己的簿记设备，并且由于寄存器已恢复，因此寄存器变量将不起作用。

当信号发生时，当前的用户上下文被保存，内核为信号处理程序创建一个新的上下文。 不要使用 longjmp(3) 离开处理程序：未定义上下文会发生什么。 请改用 siglongjmp(3) 或 setcontext()。