is NetBSD's pthread_setcancelstate() async-signal-safe?

[Richard Hansen]

Hi all,

The Austin Group (POSIX standards body) is currently considering the
following bug report:

Bug #615: pthread_setcancelstate should be async-signal-safe
http://austingroupbugs.net/view.php?id=615

Before acting on it, the group would like to know how existing
implementations behave. Is the NetBSD libpthread implementation of
pthread_setcancelstate() async-signal-safe?

Specification of pthread_setcancelstate():
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_setcancelstate.html

Definition of async-signal-safe:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_27

Also see:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03_03
http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html#tag_22_02_04_04

Thanks,
Richard

[Steffen Nurpmeso]

Richard Hansen <***@bbn.com> wrote:
|Hi all,
|
|The Austin Group (POSIX standards body) is currently considering the
|following bug report:
|
| Bug #615: pthread_setcancelstate should be async-signal-safe
| http://austingroupbugs.net/view.php?id=615
|
|Before acting on it, the group would like to know how existing

Besides NetBSD for which i can't speak i wonder where the rush
comes from? Isn't the ISO C body in the process of finding a new
definition of async-safety? I remember a message from Mr. Boehm
that said so. So how can this question be answered, then?

--steffen

[Richard Hansen]

Post by Steffen Nurpmeso

Post by Richard Hansen
Hi all,
The Austin Group (POSIX standards body) is currently considering the
Bug #615: pthread_setcancelstate should be async-signal-safe
http://austingroupbugs.net/view.php?id=615
Before acting on it, the group would like to know how existing

Besides NetBSD for which i can't speak i wonder where the rush
comes from?

There is no rush -- that bug is just the next one the group decided to
(re-)look at. Note that the bug is over a year and a half old.

Post by Steffen Nurpmeso
Isn't the ISO C body in the process of finding a new
definition of async-safety?

Do you mean C++? I am unaware of any pending changes to C regarding
signal safety, but I haven't been actively following wg14. (Nick
Stoughton is probably in a better position to answer this question.)

Post by Steffen Nurpmeso
I remember a message from Mr. Boehm that said so.

Are you referring to:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3910.html

Notable quote from the above document:

In particular, we do not want to reinvent Posix' notion of
async-signal-safe functions here.

Post by Steffen Nurpmeso
So how can this question be answered, then?

According to the POSIX Issue 7 definition of async-signal-safe. (Issue
7 is based on C99, so any changes made in C11 and later are irrelevant
for this bug, as is anything related to C++.)

Hope this helps,
Richard

[Steffen Nurpmeso]

Richard Hansen <***@bbn.com> wrote:
|On 2014-05-22 13:44, Steffen Nurpmeso wrote:
|> Richard Hansen <***@bbn.com> wrote:
|>> Hi all,
|>>
|>> The Austin Group (POSIX standards body) is currently considering the
|>> following bug report:
|>>
|>> Bug #615: pthread_setcancelstate should be async-signal-safe
|>> http://austingroupbugs.net/view.php?id=615
[.]
|> I remember a message from Mr. Boehm that said so.
|
|Are you referring to:
|http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3910.html
|
|Notable quote from the above document:
|
| In particular, we do not want to reinvent Posix' notion of
| async-signal-safe functions here.

Oh, thank you for this pointer, i didn't look wether something
moved there in the meanwhile before replying. That document is
good to read (even more for an ISO C standard track).

|> So how can this question be answered, then?
|
|According to the POSIX Issue 7 definition of async-signal-safe. (Issue
|7 is based on C99, so any changes made in C11 and later are irrelevant
|for this bug, as is anything related to C++.)

To add something of value, i personally would favour a new `async'
keyword which would act rather like RTLD_NOW does, but on
a per-variable level. To give each any every programmer a defined
tool for defining herself wether a TLS or otherwise "dynamic"ally
linked variable is usable in a signal handler or not.
One ELF section more or less, noone cares these days anyway.

|Hope this helps,

Indeed it did!
Ciao,

--steffen

[Christos Zoulas]

Post by Richard Hansen
Hi all,
The Austin Group (POSIX standards body) is currently considering the
Bug #615: pthread_setcancelstate should be async-signal-safe
http://austingroupbugs.net/view.php?id=615
Before acting on it, the group would like to know how existing
implementations behave. Is the NetBSD libpthread implementation of
pthread_setcancelstate() async-signal-safe?
http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_setcancelstate.html
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html#tag_03_27
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03_03
http://pubs.opengroup.org/onlinepubs/9699919799/xrat/V4_xsh_chap02.html#tag_22_02_04_04

I think it is not because it calls pthread_exit() indirectly.

christos