setcontext






getcontext, setcontext − get or set the user context

#include<ucontext.h>

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

In a System V‐like environment, one has the two types
mcontext_t and ucontext_t defined in <ucontext.h> and the
four functions and that allow user‐level context switching
between multiple threads of control within a process.

     The mcontext_t type is machine‐dependent and opaque.
The ucontext_t type is a structure that has at least the
following fields:

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

     with and stack_t defined in Here uc_link points to the
context that will be resumed when the current context
terminates (in case the current context was created using
uc_sigmask is the set of signals blocked in this context
(see uc_stack is the stack used by this context (see and
uc_mcontext is the machine‐specific representation of the
saved context, that includes the calling thread’s machine
registers.

     The function initializes the structure pointed at by
ucp to the currently active context.

     The function restores the user context pointed at by A
successful call does not return.  The context should have
been obtained by a call of or or passed as third argument to
a signal handler.

     If the context was obtained by a call of program
execution continues as if this call just returned.

     If the context was obtained by a call of program
execution continues by a call to the function func specified
as the second argument of that call to When the function
func returns, we continue with the uc_link member of the
structure ucp specified as the first argument of that call
to When this member is NULL, the thread exits.

     If the context was obtained by a call to a signal
handler, then old standard text says that "program execution
continues with the program instruction following the
instruction interrupted by the signal".  However, this









                             ‐2‐


sentence was removed in SUSv2, and the present verdict is
"the result is unspecified".

When successful, returns 0 and does not return.  On error,
both return −1 and set errno appropriately.

None defined.

For an explanation of the terms used in this section, see

┌───────────────────────────┬───────────────┬──────────────────┐
│Interface                  Attribute     Value            │
├───────────────────────────┼───────────────┼──────────────────┤
│                           │ Thread safety MT‐Safe race:ucp │
└───────────────────────────┴───────────────┴──────────────────┘

SUSv2, POSIX.1‐2001.  POSIX.1‐2008 removes the specification
of citing portability issues, and recommending that
applications be rewritten to use POSIX threads instead.

The earliest incarnation of this mechanism was the
mechanism.  Since that does not define the handling of the
signal context, the next stage was the pair.  The present
mechanism gives much more control.  On the other hand, there
is no easy way to detect whether a return from is from the
first call, or via a call.  The user has to invent their own
bookkeeping device, and a register variable won’t do since
registers are restored.

     When a signal occurs, the current user context is saved
and a new context is created by the kernel for the signal
handler.  Do not leave the handler using it is undefined
what would happen with contexts.  Use or instead.



This page is part of release 5.07 of the Linux man‐pages
project.  A description of the project, information about
reporting bugs, and the latest version of this page, can be
found at https://www.kernel.org/doc/man−pages/.