NOM

       getcontext, setcontext - Lire ou écrire le contexte utilisateur

SYNOPSIS

       #include <ucontext.h>

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

DESCRIPTION

       Dans  un  environnement  de  type  System V, il existe deux types mcontext_t et ucontext_t
       définis  dans  <ucontext.h>  et   les   quatre   fonctions   getcontext(),   setcontext(),
       makecontext(3)  et  swapcontext(3),  qui  permettent  le  changement de contexte au niveau
       utilisateur entre plusieurs fils de contrôle au sein du même processus (threads).

       Le type mcontext_t est opaque et  dépend  de  la  machine.  Le  type  ucontext_t  est  une
       structure ayant au moins les champs suivants :

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

       Les  types  sigset_t  et  stack_t sont définis dans <signal.h>. Ici, uc_link pointe sur le
       contexte qui doit être restauré lorsque le contexte courant se terminera (si  le  contexte
       en  cours  a  été  créé par makecontext(3)), uc_sigmask est l'ensemble des signaux bloqués
       dans ce contexte (consultez sigprocmask(2)), uc_stack est la pile utilisée par ce contexte
       (consultez sigaltstack(2)), et uc_mcontext est la représentation — dépendant de la machine
       — du contexte sauvegardé, qui inclut les registres du processeur pour le thread appelant.

       La  fonction  getcontext()  remplit  la  structure  pointée  par  ucp  avec  le   contexte
       actuellement actif.

       La  fonction setcontext() restaure le contexte utilisateur pointé par ucp. Un appel réussi
       ne revient pas.  Le  contexte  doit  avoir  été  obtenu  par  un  appel  getcontext(),  ou
       makecontext(3), ou passé en troisième argument à un gestionnaire de signal.

       Si  le  contexte  a été obtenu par un appel getcontext(), l'exécution du programme reprend
       comme si cet appel venait juste de se terminer.

       Si le contexte a été obtenu par un appel makecontext(3), l'exécution du programme continue
       par  l'appel  de  la fonction func indiquée en second argument de makecontext(3). Quand la
       fonction func se termine, on continue avec le membre uc_link de la structure ucp spécifiée
       en  premier  argument  de  l'appel  makecontext(3).  Si  ce  membre est NULL, le thread se
       termine.

       Si le contexte a été obtenu lors d'un appel à un gestionnaire de signal,  alors  le  texte
       des  anciens  standards  dit  que  « l'exécution  du programme continue avec l'instruction
       suivant celle qui a été  interrompue  par  le  signal ».  Toutefois  cette  phrase  a  été
       supprimée de SUSv2, et remplacée par "« le résultat n'est pas spécifié ».

VALEUR RENVOYÉE

       Lorsqu'ils  réussissent,  getcontext() renvoie zéro et setcontext() ne revient pas. En cas
       d'erreur, ils retournent -1 et remplissent errno avec le code d'erreur adéquat.

ERREURS

       Aucune définie.

CONFORMITÉ

       SUSv2, POSIX.1-2001. POSIX.1-2008 supprime la spécification de getcontext(), en citant des
       problèmes  de  portabilité  et  en  recommandant  à  la  place que les applications soient
       récrites en utilisant les threads POSIX.

NOTES

       L'incarnation  la  plus  ancienne  de  ce  mécanisme  était   constituée   de   la   paire
       setjmp(3)/longjmp(3).  Comme ils ne précisent pas la gestion des signaux, l'étape suivante
       fut sigsetjmp(3)/siglongjmp(3). Le mécanisme actuel donne plus de contrôle.  En  revanche,
       il  n'y  a pas de moyen simple pour savoir si le retour de getcontext() se fait depuis son
       premier appel ou par l'intermédiaire d'un appel setcontext(). L'utilisateur doit  inventer
       son propre système de comptabilisation, et pas dans un registre car il serait restauré.

       Lorsqu'un  signal  arrive,  le  contexte  utilisateur courant est sauvegardé et un nouveau
       contexte est créé par le noyau pour exécuter le gestionnaire.  N'utilisez  pas  longjmp(3)
       dans   le   gestionnaire,   le   comportement  est  indéfini.  Utilisez  siglongjmp(3)  ou
       setcontext().

VOIR AUSSI

       sigaction(2), sigaltstack(2), sigprocmask(2), longjmp(3), makecontext(3), sigsetjmp(3)

COLOPHON

       Cette page fait partie de la publication 3.57 du projet man-pages Linux.  Une  description
       du  projet  et  des  instructions  pour  signaler  des  anomalies  peuvent être trouvées à
       l'adresse http://www.kernel.org/doc/man-pages/.

TRADUCTION

       Depuis   2010,   cette   traduction   est   maintenue   à   l'aide   de    l'outil    po4a
       <http://po4a.alioth.debian.org/>  par l'équipe de traduction francophone au sein du projet
       perkamon <http://perkamon.alioth.debian.org/>.

       Veuillez     signaler     toute     erreur     de     traduction     en     écrivant     à
       <debian-l10n-french@lists.debian.org>   ou   par   un  rapport  de  bogue  sur  le  paquet
       manpages-fr.

       Vous pouvez toujours avoir accès à la version anglaise de  ce  document  en  utilisant  la
       commande « man -L C <section> <page_de_man> ».