The thread calls pthread_cleanup_pop() with a non-zero execute argument.

It is unspecified whether pthread_cleanup_push() and pthread_cleanup_pop() are macros or functions. If a macro
definition is suppressed in order to access an actual function, or a program defines an external identifier with any of these
names, the behavior is undefined. The application shall ensure that they appear as statements, and in pairs within the same lexical
scope (that is, the pthread_cleanup_push() macro may be thought to expand to a token list whose first token is '{'
with pthread_cleanup_pop() expanding to a token list whose last token is the corresponding '}' ).

The effect of calling longjmp() or siglongjmp() is undefined if there have been any calls to pthread_cleanup_push()
or pthread_cleanup_pop() made without the matching call since the jump buffer was filled. The effect of calling longjmp() or siglongjmp() from inside a
cancellation cleanup handler is also undefined unless the jump buffer was also filled in the cancellation cleanup handler.

The effect of the use of return, break, continue, and goto to prematurely leave a code block
described by a pair of pthread_cleanup_push() and pthread_cleanup_pop() functions calls is undefined.

RETURN VALUE

The pthread_cleanup_push() and pthread_cleanup_pop() functions shall not return a value.

ERRORS

No errors are defined.

These functions shall not return an error code of [EINTR].

The following sections are informative.

EXAMPLES

The following is an example using thread primitives to implement a cancelable, writers-priority read-write lock:

APPLICATION USAGE

The two routines that push and pop cancellation cleanup handlers, pthread_cleanup_push() and
pthread_cleanup_pop(), can be thought of as left and right-parentheses. They always need to be matched.

RATIONALE

The restriction that the two routines that push and pop cancellation cleanup handlers, pthread_cleanup_push() and
pthread_cleanup_pop(), have to appear in the same lexical scope allows for efficient macro or compiler implementations and
efficient storage management. A sample implementation of these routines as macros might look like this:

A more ambitious implementation of these routines might do even better by allowing the compiler to note that the cancellation
cleanup handler is a constant and can be expanded inline.

This volume of POSIX.1-2008 currently leaves unspecified the effect of calling longjmp() from a signal handler executing in a POSIX System Interfaces function. If an
implementation wants to allow this and give the programmer reasonable behavior, the longjmp() function has to call all cancellation cleanup handlers that have been pushed but
not popped since the time setjmp() was called.

Consider a multi-threaded function called by a thread that uses signals. If a signal were delivered to a signal handler during
the operation of qsort() and that handler were to call longjmp() (which, in turn, did not call the cancellation cleanup handlers) the helper
threads created by the qsort() function would not be canceled. Instead, they would
continue to execute and write into the argument array even though the array might have been popped off the stack.

Note that the specified cleanup handling mechanism is especially tied to the C language and, while the requirement for a uniform
mechanism for expressing cleanup is language-independent, the mechanism used in other languages may be quite different. In
addition, this mechanism is really only necessary due to the lack of a real exception mechanism in the C language, which would be
the ideal solution.

There is no notion of a cancellation cleanup-safe function. If an application has no cancellation points in its signal handlers,
blocks any signal whose handler may have cancellation points while calling async-unsafe functions, or disables cancellation while
calling async-unsafe functions, all functions may be safely called from cancellation cleanup routines.

FUTURE DIRECTIONS

SEE ALSO

CHANGE HISTORY

First released in Issue 5. Included for alignment with the POSIX Threads Extension.

Issue 6

The pthread_cleanup_pop() and pthread_cleanup_push() functions are marked as part of the Threads option.

The APPLICATION USAGE section is added.

The normative text is updated to avoid use of the term "must" for application requirements.

IEEE Std 1003.1-2001/Cor 2-2004, item XSH/TC2/D6/88 is applied, updating the DESCRIPTION to describe the
consequences of prematurely leaving a code block defined by the pthread_cleanup_push() and pthread_cleanup_pop()
functions.

Issue 7

The pthread_cleanup_pop() and pthread_cleanup_push() functions are moved from the Threads option to the Base.