From 7c6776620db8e48fca492dbcac88d1c0f239dcde Mon Sep 17 00:00:00 2001 From: Will Newton Date: Thu, 13 Mar 2014 09:45:29 +0000 Subject: [PATCH] manual/setjmp.texi: Clarify setcontext and signal handlers text Calling setcontext from a signal handler can be done safely so it is sufficient to note that it is not recommended. Also mention in setcontext documentation that the behaviour of setcontext when restoring a context created by a call to a signal handler is unspecified. 2014-04-17 Will Newton * manual/setjmp.texi (System V contexts): Add note that calling setcontext on a context created by a call to a signal handler is undefined. Update text to note that setcontext from a signal handler is possible but not recommended. --- ChangeLog | 6 ++++++ manual/setjmp.texi | 19 +++++++++++-------- 2 files changed, 17 insertions(+), 8 deletions(-) diff --git a/ChangeLog b/ChangeLog index 1dd40fcf2c..7267472884 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,11 @@ 2014-04-17 Will Newton + * manual/setjmp.texi (System V contexts): Add note that + calling setcontext on a context created by a call to a + signal handler is undefined. Update text to note that + setcontext from a signal handler is possible but not + recommended. + [BZ #16629] * stdlib/tst-setcontext.c: Include signal.h. (main): Check that the signal stack before and diff --git a/manual/setjmp.texi b/manual/setjmp.texi index 9446abcff7..ec79c26bb3 100644 --- a/manual/setjmp.texi +++ b/manual/setjmp.texi @@ -396,6 +396,9 @@ time of the call. If @code{uc_link} was a null pointer the application terminates normally with an exit status value of @code{EXIT_SUCCESS} (@pxref{Program Termination}). +If the context was created by a call to a signal handler or from any +other source then the behaviour of @code{setcontext} is unspecified. + Since the context contains information about the stack no two threads should use the same context at the same time. The result in most cases would be disastrous. @@ -483,11 +486,11 @@ and then resume where execution was stopped. This an example how the context functions can be used to implement co-routines or cooperative multi-threading. All that has to be done is to call every once in a while @code{swapcontext} to continue running a -different context. It is not allowed to do the context switching from -the signal handler directly since neither @code{setcontext} nor -@code{swapcontext} are functions which can be called from a signal -handler. But setting a variable in the signal handler and checking it -in the body of the functions which are executed is OK. Since -@code{swapcontext} is saving the current context it is possible to have -multiple different scheduling points in the code. Execution will always -resume where it was left. +different context. It is not recommended to do the context switching from +the signal handler directly since leaving the signal handler via +@code{setcontext} if the signal was delivered during code that was not +asynchronous signal safe could lead to problems. Setting a variable in +the signal handler and checking it in the body of the functions which +are executed is a safer approach. Since @code{swapcontext} is saving the +current context it is possible to have multiple different scheduling points +in the code. Execution will always resume where it was left. -- 2.11.4.GIT