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  <will.newton@linaro.org>

	* 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.

1 files changed, 11 insertions, 8 deletions

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.