diff options
| author | Carlos O'Donell <carlos@redhat.com> | 2019-10-04 17:12:08 -0400 |
|---|---|---|
| committer | Michael Kerrisk <mtk.manpages@gmail.com> | 2019-10-05 14:54:02 +0300 |
| commit | dbb01cbbdb60c34a16d9d48cb58ed3680a5dd36d (patch) | |
| tree | 588077e10e6c281da502e1137bfdc4c8aab58c8a /man7/pthreads.7 | |
| parent | c6ed23c5da678bc89b8fee6370f65ddd3e8b4907 (diff) | |
| download | man-pages-dbb01cbbdb60c34a16d9d48cb58ed3680a5dd36d.tar.gz | |
pthread_setcancelstate.3, pthreads.7, signal-safety.7: Describe issues with cancellation points in signal handlers
In a recent conversation with Mathieu Desnoyers I was reminded
that we haven't written up anything about how deferred
cancellation and asynchronous signal handlers interact. Mathieu
ran into some of this behaviour and I promised to improve the
documentation in this area to point out the potential pitfall.
Thoughts?
8< --- 8< --- 8<
In pthread_setcancelstate.3, pthreads.7, and signal-safety.7 we
describe that if you have an asynchronous signal nesting over a
deferred cancellation region that any cancellation point in the
signal handler may trigger a cancellation that will behave
as-if it was an asynchronous cancellation. This asynchronous
cancellation may have unexpected effects on the consistency of
the application. Therefore care should be taken with asynchronous
signals and deferred cancellation.
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
Diffstat (limited to 'man7/pthreads.7')
| -rw-r--r-- | man7/pthreads.7 | 9 |
1 files changed, 9 insertions, 0 deletions
diff --git a/man7/pthreads.7 b/man7/pthreads.7 index 06417d503a..b39236c398 100644 --- a/man7/pthreads.7 +++ b/man7/pthreads.7 @@ -564,6 +564,15 @@ not specified in the standard as cancellation points. In particular, an implementation is likely to mark any nonstandard function that may block as a cancellation point. (This includes most functions that can touch files.) +.in +.PP +It should be noted that even if an application is not using +asynchronous cancellation, that calling a function from the above list +from an asynchronous signal handler may cause the equivalent of +asynchronous cancellation. The underlying user code may not expect +asynchronous cancellation and the state of the user data may become +inconsistent. Therefore signals should be used with caution when +entering a region of deferred cancellation. .\" So, scanning "cancellation point" comments in the glibc 2.8 header .\" files, it looks as though at least the following nonstandard .\" functions are cancellation points: |