Clarification of pthread_cleanup_push() needed

Clarification of pthread_cleanup_push() needed

[Richard Weinberger]

Hi!

Using pthread_cleanup_push() it is possible to register a cleanup
routine which will get
called upon thread cancellation.
I have a hard time to understand what exactly this routine allowed to
do and what not.

The manpage states:
"A clean-up handler is a function that is automatically executed when
a thread is
canceled (or in various other circumstances described below); it
might, for example,
unlock a mutex so that it becomes available to other threads in the process."

https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_cleanup_push.html
even has an example with pthread_mutex_unlock() in the cleanup
function.

But NPTL implements thread cancellation with signals, if I'm not
completely mistaken
the cleanup routine will run in signal context then.
So only async-signal-safe functions are good to use.
pthread_mutex_unlock() is not.

With my (limited) understanding of the current NPTL implementation I'd
say a cleanup routine
might only use async-signal-safe functions, except long jumps.

Can you please clarify?
And can we please state this more precisely in the manpage?

-- 
Thanks,
//richard

Re: Clarification of pthread_cleanup_push() needed

[Florian Weimer]

* Richard Weinberger via Libc-help:

> But NPTL implements thread cancellation with signals, if I'm not
> completely mistaken the cleanup routine will run in signal context
> then.

Deferred cancellation only occurs in signal context if the
cancellation is acted upon from within a signal handler.  For the
signal handler case, whether cancellation handlers are restricted to
async-signal-safe function calls depends on the type of signal (some
are synchronous, not asynchronous) and what is interrupted by the
signal (for asynchronous signals).

Asynchronous cancellation has even more constraints than asynchronous
signal safety, but it is rarely used.

Re: Clarification of pthread_cleanup_push() needed

[Richard Weinberger]

On Tue, Apr 21, 2020 at 11:41 PM Florian Weimer <fw@deneb.enyo.de> wrote:
>
> * Richard Weinberger via Libc-help:
>
> > But NPTL implements thread cancellation with signals, if I'm not
> > completely mistaken the cleanup routine will run in signal context
> > then.
>
> Deferred cancellation only occurs in signal context if the
> cancellation is acted upon from within a signal handler.  For the
> signal handler case, whether cancellation handlers are restricted to
> async-signal-safe function calls depends on the type of signal (some
> are synchronous, not asynchronous) and what is interrupted by the
> signal (for asynchronous signals).
>
> Asynchronous cancellation has even more constraints than asynchronous
> signal safety, but it is rarely used.

I should have noted that I'm using asynchronous cancellation.
Which constraints are these?

-- 
Thanks,
//richard

Re: Clarification of pthread_cleanup_push() needed

[Florian Weimer]

* Richard Weinberger:

> On Tue, Apr 21, 2020 at 11:41 PM Florian Weimer <fw@deneb.enyo.de> wrote:
>>
>> * Richard Weinberger via Libc-help:
>>
>> > But NPTL implements thread cancellation with signals, if I'm not
>> > completely mistaken the cleanup routine will run in signal context
>> > then.
>>
>> Deferred cancellation only occurs in signal context if the
>> cancellation is acted upon from within a signal handler.  For the
>> signal handler case, whether cancellation handlers are restricted to
>> async-signal-safe function calls depends on the type of signal (some
>> are synchronous, not asynchronous) and what is interrupted by the
>> signal (for asynchronous signals).
>>
>> Asynchronous cancellation has even more constraints than asynchronous
>> signal safety, but it is rarely used.
>
> I should have noted that I'm using asynchronous cancellation.
> Which constraints are these?

See pthread_setcanceltype(3):

  Functions that can be safely asynchronously canceled are called
  async-cancel-safe functions.  POSIX.1-2001 and POSIX.1-2008 require
  only that pthread_cancel(3), pthread_setcancelstate(), and
  pthread_setcanceltype() be async-cancel-safe.  In general, other
  library functions can't be safely called from an asynchronously
  cancelable thread.

The manual pages and the glibc manual also contain information about
AC-safety, but you cannot rely on them.  They depend on implementation
details which may change within release branches.

Re: Clarification of pthread_cleanup_push() needed

[Richard Weinberger]

On Wed, Apr 22, 2020 at 12:12 AM Florian Weimer <fw@deneb.enyo.de> wrote:
>
> * Richard Weinberger:
>
> > On Tue, Apr 21, 2020 at 11:41 PM Florian Weimer <fw@deneb.enyo.de> wrote:
> >>
> >> * Richard Weinberger via Libc-help:
> >>
> >> > But NPTL implements thread cancellation with signals, if I'm not
> >> > completely mistaken the cleanup routine will run in signal context
> >> > then.
> >>
> >> Deferred cancellation only occurs in signal context if the
> >> cancellation is acted upon from within a signal handler.  For the
> >> signal handler case, whether cancellation handlers are restricted to
> >> async-signal-safe function calls depends on the type of signal (some
> >> are synchronous, not asynchronous) and what is interrupted by the
> >> signal (for asynchronous signals).
> >>
> >> Asynchronous cancellation has even more constraints than asynchronous
> >> signal safety, but it is rarely used.
> >
> > I should have noted that I'm using asynchronous cancellation.
> > Which constraints are these?
>
> See pthread_setcanceltype(3):
>
>   Functions that can be safely asynchronously canceled are called
>   async-cancel-safe functions.  POSIX.1-2001 and POSIX.1-2008 require
>   only that pthread_cancel(3), pthread_setcancelstate(), and
>   pthread_setcanceltype() be async-cancel-safe.  In general, other
>   library functions can't be safely called from an asynchronously
>   cancelable thread.
>
> The manual pages and the glibc manual also contain information about
> AC-safety, but you cannot rely on them.  They depend on implementation
> details which may change within release branches.

Well, this manpage does not talk much about the cleanup routine, except for
"Consequently, clean-up handlers cease to be useful", which is clear as mud.

I'm well aware that async cancel is not nice at all and my code can be
interrupted
at any time.

Back to the cleanup routine, with asynchronous cancellation:
- it must not use any function which might got interrupted by cancel,
- it may only use async-signal-safe function, except long jumps.

Is this correct?

To give you some background, I'm porting an application to NPTL which comes
from an operating system where cancelling threads and automatic
cleanup is the way to go.
Completely rewriting the application is not an option, so I need to
figure how far I get with
pthread_cancel() and friends.

-- 
Thanks,
//richard

Re: Clarification of pthread_cleanup_push() needed

[Florian Weimer]

* Richard Weinberger:

> Well, this manpage does not talk much about the cleanup routine, except for
> "Consequently, clean-up handlers cease to be useful", which is clear as mud.

I think this refers to the fact that pthread_cleanup_push and
pthread_cleanup_pop are not necessarily async-cancel-safe.

> Back to the cleanup routine, with asynchronous cancellation:
> - it must not use any function which might got interrupted by cancel,
> - it may only use async-signal-safe function, except long jumps.
>
> Is this correct?

I think there are no restrictions on the cleanup handler *contents*
due to asynchronous cancellation.  The restrictions are on the code
that is interrupted.

You need to find a way to safely register them.  Code compiled by GCC
with -fexceptions and -fasynchronous-unwind-tables should work,
though.  In that case, the cleanup handler is not explicitly
registered, but implicitly identified by the region of code within
which the program counter is located during asynchronous cancellation.

> To give you some background, I'm porting an application to NPTL
> which comes from an operating system where cancelling threads and
> automatic cleanup is the way to go.

Do you have a list of functions that need to be async-cancel-safe for
this purpose?