OpenE2K
/
glibc
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

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.
This commit is contained in:
Will Newton 2014-03-13 09:45:29 +00:00
parent e04a4e9d2e
commit 7c6776620d
2 changed files with 17 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
ChangeLog
View File

@ -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

19
manual/setjmp.texi
View File

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