aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorWill Newton <will.newton@linaro.org>2014-03-13 09:45:29 +0000
committerWill Newton <will.newton@linaro.org>2014-04-17 11:40:36 +0100
commit7c6776620db8e48fca492dbcac88d1c0f239dcde (patch)
tree046a6f9a10d27442429c6c50b0e0f32fac286936
parente04a4e9d2e639a7770e1c0d24ecbcf92abf6bba8 (diff)
downloadglibc-7c6776620db8e48fca492dbcac88d1c0f239dcde.tar
glibc-7c6776620db8e48fca492dbcac88d1c0f239dcde.tar.gz
glibc-7c6776620db8e48fca492dbcac88d1c0f239dcde.tar.bz2
glibc-7c6776620db8e48fca492dbcac88d1c0f239dcde.zip
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.
-rw-r--r--ChangeLog6
-rw-r--r--manual/setjmp.texi19
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 <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.
+
[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.