Linux-man Archive on lore.kernel.org
 help / color / Atom feed
* [PATCH] pthread_kill.3: Update to match POSIX.
@ 2019-11-12 20:36 enh
  2019-11-12 21:38 ` Florian Weimer
  0 siblings, 1 reply; 12+ messages in thread
From: enh @ 2019-11-12 20:36 UTC (permalink / raw)
  To: Michael Kerrisk (man-pages); +Cc: linux-man

[-- Attachment #1: Type: text/plain, Size: 2279 bytes --]

POSIX removed ESRCH years ago.

In resolving http://austingroupbugs.net/view.php?id=1214 it was made
clear that callers can't rely on using signal 0 to test for the
continued existence of a thread. Update the man page to make it clearer
that this doesn't generally work (even if it sometimes seems to).

See also the long explanation of why this is the case (and how to fix
your code) here:

https://android.googlesource.com/platform/bionic/+/master/docs/status.md#invalid-handling-targetsdkversion-o
---
 man3/pthread_kill.3 | 25 +++++++++----------------
 1 file changed, 9 insertions(+), 16 deletions(-)

diff --git a/man3/pthread_kill.3 b/man3/pthread_kill.3
index e70e2669e..fb27afd24 100644
--- a/man3/pthread_kill.3
+++ b/man3/pthread_kill.3
@@ -56,10 +56,6 @@ to
 a thread in the same process as the caller.
 The signal is asynchronously directed to
 .IR thread .
-.PP
-If
-.I sig
-is 0, then no signal is sent, but error checking is still performed.
 .SH RETURN VALUE
 On success,
 .BR pthread_kill ()
@@ -93,26 +89,23 @@ this action will affect the whole process.
 .PP
 The glibc implementation of
 .BR pthread_kill ()
-gives an error
-.RB ( EINVAL )
+gives the error
+.B EINVAL
 on attempts to send either of the real-time signals
 used internally by the NPTL threading implementation.
 See
 .BR nptl (7)
 for details.
 .PP
-POSIX.1-2008 recommends that if an implementation detects the use
-of a thread ID after the end of its lifetime,
+The glibc implementation of
 .BR pthread_kill ()
-should return the error
-.BR ESRCH .
-The glibc implementation returns this error in the cases where
-an invalid thread ID can be detected.
-But note also that POSIX says that an attempt to use a thread ID whose
-lifetime has ended produces undefined behavior,
-and an attempt to use an invalid thread ID in a call to
+tries to give the error
+.B ESRCH
+on attempts to use an invalid thread ID, but this isn't always possible.
+An attempt to use an invalid thread ID in a call to
 .BR pthread_kill ()
-can, for example, cause a segmentation fault.
+can, for example, cause a segmentation fault. Android is stricter, and will
+always abort when a pthread function is given an invalid thread ID.
 .SH SEE ALSO
 .BR kill (2),
 .BR sigaction (2),
-- 
2.24.0.rc1.363.gb1bccd3e3d-goog

[-- Attachment #2: 0001-pthread_kill.3-Update-to-match-POSIX.patch --]
[-- Type: text/x-patch, Size: 2484 bytes --]

From 656249792d1782e2d8ca581663ee88b19181b084 Mon Sep 17 00:00:00 2001
From: Elliott Hughes <enh@google.com>
Date: Tue, 12 Nov 2019 12:19:52 -0800
Subject: [PATCH] pthread_kill.3: Update to match POSIX.

POSIX removed ESRCH years ago.

In resolving http://austingroupbugs.net/view.php?id=1214 it was made
clear that callers can't rely on using signal 0 to test for the
continued existence of a thread. Update the man page to make it clearer
that this doesn't generally work (even if it sometimes seems to).

See also the long explanation of why this is the case (and how to fix
your code) here:

https://android.googlesource.com/platform/bionic/+/master/docs/status.md#invalid-handling-targetsdkversion-o
---
 man3/pthread_kill.3 | 25 +++++++++----------------
 1 file changed, 9 insertions(+), 16 deletions(-)

diff --git a/man3/pthread_kill.3 b/man3/pthread_kill.3
index e70e2669e..fb27afd24 100644
--- a/man3/pthread_kill.3
+++ b/man3/pthread_kill.3
@@ -56,10 +56,6 @@ to
 a thread in the same process as the caller.
 The signal is asynchronously directed to
 .IR thread .
-.PP
-If
-.I sig
-is 0, then no signal is sent, but error checking is still performed.
 .SH RETURN VALUE
 On success,
 .BR pthread_kill ()
@@ -93,26 +89,23 @@ this action will affect the whole process.
 .PP
 The glibc implementation of
 .BR pthread_kill ()
-gives an error
-.RB ( EINVAL )
+gives the error
+.B EINVAL
 on attempts to send either of the real-time signals
 used internally by the NPTL threading implementation.
 See
 .BR nptl (7)
 for details.
 .PP
-POSIX.1-2008 recommends that if an implementation detects the use
-of a thread ID after the end of its lifetime,
+The glibc implementation of
 .BR pthread_kill ()
-should return the error
-.BR ESRCH .
-The glibc implementation returns this error in the cases where
-an invalid thread ID can be detected.
-But note also that POSIX says that an attempt to use a thread ID whose
-lifetime has ended produces undefined behavior,
-and an attempt to use an invalid thread ID in a call to
+tries to give the error
+.B ESRCH
+on attempts to use an invalid thread ID, but this isn't always possible.
+An attempt to use an invalid thread ID in a call to
 .BR pthread_kill ()
-can, for example, cause a segmentation fault.
+can, for example, cause a segmentation fault. Android is stricter, and will
+always abort when a pthread function is given an invalid thread ID.
 .SH SEE ALSO
 .BR kill (2),
 .BR sigaction (2),
-- 
2.24.0.rc1.363.gb1bccd3e3d-goog


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] pthread_kill.3: Update to match POSIX.
  2019-11-12 20:36 [PATCH] pthread_kill.3: Update to match POSIX enh
@ 2019-11-12 21:38 ` Florian Weimer
  2019-11-12 21:40   ` enh
  0 siblings, 1 reply; 12+ messages in thread
From: Florian Weimer @ 2019-11-12 21:38 UTC (permalink / raw)
  To: enh; +Cc: Michael Kerrisk \(man-pages\), linux-man

* enh:

> POSIX removed ESRCH years ago.
>
> In resolving http://austingroupbugs.net/view.php?id=1214 it was made
> clear that callers can't rely on using signal 0 to test for the
> continued existence of a thread. Update the man page to make it clearer
> that this doesn't generally work (even if it sometimes seems to).
>
> See also the long explanation of why this is the case (and how to fix
> your code) here:
>
> https://android.googlesource.com/platform/bionic/+/master/docs/status.md#invalid-handling-targetsdkversion-o

Well, if you fix the thread exit race (like musl did, and glibc should
as well, see bug 12889), you could get a reliable ESRCH as a side
effect.  Pity that POSIX doesn't allow that.

I think this might be a case where common (but not unavoidable)
implementation problems get in the way of a better standard.  Usually,
it's the other way round.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] pthread_kill.3: Update to match POSIX.
  2019-11-12 21:38 ` Florian Weimer
@ 2019-11-12 21:40   ` enh
  2019-11-12 21:52     ` Florian Weimer
  0 siblings, 1 reply; 12+ messages in thread
From: enh @ 2019-11-12 21:40 UTC (permalink / raw)
  To: Florian Weimer; +Cc: Michael Kerrisk (man-pages), linux-man

On Tue, Nov 12, 2019 at 1:38 PM Florian Weimer <fw@deneb.enyo.de> wrote:
>
> * enh:
>
> > POSIX removed ESRCH years ago.
> >
> > In resolving http://austingroupbugs.net/view.php?id=1214 it was made
> > clear that callers can't rely on using signal 0 to test for the
> > continued existence of a thread. Update the man page to make it clearer
> > that this doesn't generally work (even if it sometimes seems to).
> >
> > See also the long explanation of why this is the case (and how to fix
> > your code) here:
> >
> > https://android.googlesource.com/platform/bionic/+/master/docs/status.md#invalid-handling-targetsdkversion-o
>
> Well, if you fix the thread exit race (like musl did, and glibc should
> as well, see bug 12889), you could get a reliable ESRCH as a side
> effect.  Pity that POSIX doesn't allow that.

this isn't about the tid stored *in* the object that the pthread_t points to.

like i (briefly) said in the commit message, this is because a
pthread_t is a pointer, so if you have an old pthread_t that's been
recycled... boom!

> I think this might be a case where common (but not unavoidable)
> implementation problems get in the way of a better standard.  Usually,
> it's the other way round.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] pthread_kill.3: Update to match POSIX.
  2019-11-12 21:40   ` enh
@ 2019-11-12 21:52     ` Florian Weimer
  2019-11-12 22:06       ` enh
  0 siblings, 1 reply; 12+ messages in thread
From: Florian Weimer @ 2019-11-12 21:52 UTC (permalink / raw)
  To: enh; +Cc: Michael Kerrisk \(man-pages\), linux-man

* enh:

> On Tue, Nov 12, 2019 at 1:38 PM Florian Weimer <fw@deneb.enyo.de> wrote:
>>
>> * enh:
>>
>> > POSIX removed ESRCH years ago.
>> >
>> > In resolving http://austingroupbugs.net/view.php?id=1214 it was made
>> > clear that callers can't rely on using signal 0 to test for the
>> > continued existence of a thread. Update the man page to make it clearer
>> > that this doesn't generally work (even if it sometimes seems to).
>> >
>> > See also the long explanation of why this is the case (and how to fix
>> > your code) here:
>> >
>> > https://android.googlesource.com/platform/bionic/+/master/docs/status.md#invalid-handling-targetsdkversion-o
>>
>> Well, if you fix the thread exit race (like musl did, and glibc should
>> as well, see bug 12889), you could get a reliable ESRCH as a side
>> effect.  Pity that POSIX doesn't allow that.
>
> this isn't about the tid stored *in* the object that the pthread_t points to.
>
> like i (briefly) said in the commit message, this is because a
> pthread_t is a pointer, so if you have an old pthread_t that's been
> recycled... boom!

Backing storage for a pthread_t object denoting a joinable thread
cannot be recycled, so that's not the case here.  POSIX mandates
returning success even if the implementation has detected that it must
not send the signal because the thread has already terminated.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] pthread_kill.3: Update to match POSIX.
  2019-11-12 21:52     ` Florian Weimer
@ 2019-11-12 22:06       ` enh
  2019-11-12 22:11         ` Florian Weimer
  0 siblings, 1 reply; 12+ messages in thread
From: enh @ 2019-11-12 22:06 UTC (permalink / raw)
  To: Florian Weimer; +Cc: Michael Kerrisk (man-pages), linux-man

On Tue, Nov 12, 2019 at 1:52 PM Florian Weimer <fw@deneb.enyo.de> wrote:
>
> * enh:
>
> > On Tue, Nov 12, 2019 at 1:38 PM Florian Weimer <fw@deneb.enyo.de> wrote:
> >>
> >> * enh:
> >>
> >> > POSIX removed ESRCH years ago.
> >> >
> >> > In resolving http://austingroupbugs.net/view.php?id=1214 it was made
> >> > clear that callers can't rely on using signal 0 to test for the
> >> > continued existence of a thread. Update the man page to make it clearer
> >> > that this doesn't generally work (even if it sometimes seems to).
> >> >
> >> > See also the long explanation of why this is the case (and how to fix
> >> > your code) here:
> >> >
> >> > https://android.googlesource.com/platform/bionic/+/master/docs/status.md#invalid-handling-targetsdkversion-o
> >>
> >> Well, if you fix the thread exit race (like musl did, and glibc should
> >> as well, see bug 12889), you could get a reliable ESRCH as a side
> >> effect.  Pity that POSIX doesn't allow that.
> >
> > this isn't about the tid stored *in* the object that the pthread_t points to.
> >
> > like i (briefly) said in the commit message, this is because a
> > pthread_t is a pointer, so if you have an old pthread_t that's been
> > recycled... boom!
>
> Backing storage for a pthread_t object denoting a joinable thread
> cannot be recycled, so that's not the case here.  POSIX mandates
> returning success even if the implementation has detected that it must
> not send the signal because the thread has already terminated.

who said anything about joinable?

the cases we've seen in practice are that folks incorrectly believe
that pthread_kill(3) with a signal of 0 is a reliable way to test
whether a thread is still running.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] pthread_kill.3: Update to match POSIX.
  2019-11-12 22:06       ` enh
@ 2019-11-12 22:11         ` Florian Weimer
  2019-11-12 22:22           ` enh
  0 siblings, 1 reply; 12+ messages in thread
From: Florian Weimer @ 2019-11-12 22:11 UTC (permalink / raw)
  To: enh; +Cc: Michael Kerrisk \(man-pages\), linux-man

* enh:

> On Tue, Nov 12, 2019 at 1:52 PM Florian Weimer <fw@deneb.enyo.de> wrote:
>>
>> * enh:
>>
>> > On Tue, Nov 12, 2019 at 1:38 PM Florian Weimer <fw@deneb.enyo.de> wrote:
>> >>
>> >> * enh:
>> >>
>> >> > POSIX removed ESRCH years ago.
>> >> >
>> >> > In resolving http://austingroupbugs.net/view.php?id=1214 it was made
>> >> > clear that callers can't rely on using signal 0 to test for the
>> >> > continued existence of a thread. Update the man page to make it clearer
>> >> > that this doesn't generally work (even if it sometimes seems to).
>> >> >
>> >> > See also the long explanation of why this is the case (and how to fix
>> >> > your code) here:
>> >> >
>> >> > https://android.googlesource.com/platform/bionic/+/master/docs/status.md#invalid-handling-targetsdkversion-o
>> >>
>> >> Well, if you fix the thread exit race (like musl did, and glibc should
>> >> as well, see bug 12889), you could get a reliable ESRCH as a side
>> >> effect.  Pity that POSIX doesn't allow that.
>> >
>> > this isn't about the tid stored *in* the object that the pthread_t
>> > points to.
>> >
>> > like i (briefly) said in the commit message, this is because a
>> > pthread_t is a pointer, so if you have an old pthread_t that's been
>> > recycled... boom!
>>
>> Backing storage for a pthread_t object denoting a joinable thread
>> cannot be recycled, so that's not the case here.  POSIX mandates
>> returning success even if the implementation has detected that it must
>> not send the signal because the thread has already terminated.
>
> who said anything about joinable?

That determines whether the pthread_t object is still valid.

> the cases we've seen in practice are that folks incorrectly believe
> that pthread_kill(3) with a signal of 0 is a reliable way to test
> whether a thread is still running.

Right, that's not working according to (future) POSIX.  Which I
dislike because a correct implementation of pthread_kill has to do all
the work to support this usage (or something like it; after all, only
testing for termination gives stable results), and then is forced by
POSIX to discard the data.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] pthread_kill.3: Update to match POSIX.
  2019-11-12 22:11         ` Florian Weimer
@ 2019-11-12 22:22           ` enh
  2019-11-12 22:28             ` Florian Weimer
  0 siblings, 1 reply; 12+ messages in thread
From: enh @ 2019-11-12 22:22 UTC (permalink / raw)
  To: Florian Weimer; +Cc: Michael Kerrisk (man-pages), linux-man

On Tue, Nov 12, 2019 at 2:11 PM Florian Weimer <fw@deneb.enyo.de> wrote:
>
> * enh:
>
> > On Tue, Nov 12, 2019 at 1:52 PM Florian Weimer <fw@deneb.enyo.de> wrote:
> >>
> >> * enh:
> >>
> >> > On Tue, Nov 12, 2019 at 1:38 PM Florian Weimer <fw@deneb.enyo.de> wrote:
> >> >>
> >> >> * enh:
> >> >>
> >> >> > POSIX removed ESRCH years ago.
> >> >> >
> >> >> > In resolving http://austingroupbugs.net/view.php?id=1214 it was made
> >> >> > clear that callers can't rely on using signal 0 to test for the
> >> >> > continued existence of a thread. Update the man page to make it clearer
> >> >> > that this doesn't generally work (even if it sometimes seems to).
> >> >> >
> >> >> > See also the long explanation of why this is the case (and how to fix
> >> >> > your code) here:
> >> >> >
> >> >> > https://android.googlesource.com/platform/bionic/+/master/docs/status.md#invalid-handling-targetsdkversion-o
> >> >>
> >> >> Well, if you fix the thread exit race (like musl did, and glibc should
> >> >> as well, see bug 12889), you could get a reliable ESRCH as a side
> >> >> effect.  Pity that POSIX doesn't allow that.
> >> >
> >> > this isn't about the tid stored *in* the object that the pthread_t
> >> > points to.
> >> >
> >> > like i (briefly) said in the commit message, this is because a
> >> > pthread_t is a pointer, so if you have an old pthread_t that's been
> >> > recycled... boom!
> >>
> >> Backing storage for a pthread_t object denoting a joinable thread
> >> cannot be recycled, so that's not the case here.  POSIX mandates
> >> returning success even if the implementation has detected that it must
> >> not send the signal because the thread has already terminated.
> >
> > who said anything about joinable?
>
> That determines whether the pthread_t object is still valid.

but this is all about *invalid* threads, which obviously can't be
joinable. i'm really not sure what you're trying to say.

> > the cases we've seen in practice are that folks incorrectly believe
> > that pthread_kill(3) with a signal of 0 is a reliable way to test
> > whether a thread is still running.
>
> Right, that's not working according to (future) POSIX.  Which I
> dislike because a correct implementation of pthread_kill has to do all
> the work to support this usage (or something like it; after all, only
> testing for termination gives stable results), and then is forced by
> POSIX to discard the data.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] pthread_kill.3: Update to match POSIX.
  2019-11-12 22:22           ` enh
@ 2019-11-12 22:28             ` Florian Weimer
  2019-11-13  5:27               ` enh
  0 siblings, 1 reply; 12+ messages in thread
From: Florian Weimer @ 2019-11-12 22:28 UTC (permalink / raw)
  To: enh; +Cc: Michael Kerrisk \(man-pages\), linux-man

* enh:

> but this is all about *invalid* threads, which obviously can't be
> joinable. i'm really not sure what you're trying to say.

Uhm, people try use pthread_kill to probe for thread termination.
Termintation of a non-detached thread doesn't make a thread
non-joinable, so from a temporal memory safety perspective, that's
totally fine.  Except that POSIX requires implementations to hide this
information from callers.

Maybe we are talking past each other, though.

Let's look at what musl does:

int pthread_kill(pthread_t t, int sig)
{
        int r;
        LOCK(t->killlock);
        r = t->tid ? -__syscall(SYS_tkill, t->tid, sig)
                : (sig+0U >= _NSIG ? EINVAL : 0);
        UNLOCK(t->killlock);
        return r;
}

The 0 could be ESRCH to support probing for termination.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] pthread_kill.3: Update to match POSIX.
  2019-11-12 22:28             ` Florian Weimer
@ 2019-11-13  5:27               ` enh
  2019-11-13  5:51                 ` Florian Weimer
  0 siblings, 1 reply; 12+ messages in thread
From: enh @ 2019-11-13  5:27 UTC (permalink / raw)
  To: Florian Weimer; +Cc: Michael Kerrisk (man-pages), linux-man

On Tue, Nov 12, 2019 at 2:28 PM Florian Weimer <fw@deneb.enyo.de> wrote:
>
> * enh:
>
> > but this is all about *invalid* threads, which obviously can't be
> > joinable. i'm really not sure what you're trying to say.
>
> Uhm, people try use pthread_kill to probe for thread termination.

yes, that's why i'm keen that we make it clearer that this doesn't work.

> Termintation of a non-detached thread doesn't make a thread
> non-joinable, so from a temporal memory safety perspective, that's
> totally fine.  Except that POSIX requires implementations to hide this
> information from callers.
>
> Maybe we are talking past each other, though.
>
> Let's look at what musl does:
>
> int pthread_kill(pthread_t t, int sig)
> {
>         int r;
>         LOCK(t->killlock);
>         r = t->tid ? -__syscall(SYS_tkill, t->tid, sig)
>                 : (sig+0U >= _NSIG ? EINVAL : 0);
>         UNLOCK(t->killlock);
>         return r;
> }
>
> The 0 could be ESRCH to support probing for termination.

no, because the C library has two choices when a thread exits:

1. unmap the thread.

2. keep the thread around for recycling.

if you choose 1 (optimizing for space, like Android), your dereference
is illegal.

if you choose 2 (optimizing for time, as i believe glibc does), your
dereference is fine and you read the zero that the kernel put there
... until the thread is reused. now you're actually looking at a
different thread than the one you think you're looking at. and as a
caller who by definition doesn't know the current state of the thread,
you've no idea whether it's been reused or not. (this is also strictly
the case on Android if ASLR has put a new thread's stack where the old
one used to be.)

there's more detail about this -- and some less unreliable options --
in the Android documentation i linked to in the commit message.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] pthread_kill.3: Update to match POSIX.
  2019-11-13  5:27               ` enh
@ 2019-11-13  5:51                 ` Florian Weimer
  2019-11-13  5:59                   ` enh
  0 siblings, 1 reply; 12+ messages in thread
From: Florian Weimer @ 2019-11-13  5:51 UTC (permalink / raw)
  To: enh; +Cc: Michael Kerrisk \(man-pages\), linux-man

* enh:

> no, because the C library has two choices when a thread exits:
>
> 1. unmap the thread.
>
> 2. keep the thread around for recycling.
>
> if you choose 1 (optimizing for space, like Android), your dereference
> is illegal.

This choice is only available for threads in a detached state.  For
joinable threads, a conforming implementation cannot immediately
deallocate all data structures on thread termination.  Among other
things, it has to store the future return value of pthread_join
somewhere.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] pthread_kill.3: Update to match POSIX.
  2019-11-13  5:51                 ` Florian Weimer
@ 2019-11-13  5:59                   ` enh
  2019-11-13  6:10                     ` Florian Weimer
  0 siblings, 1 reply; 12+ messages in thread
From: enh @ 2019-11-13  5:59 UTC (permalink / raw)
  To: Florian Weimer; +Cc: Michael Kerrisk (man-pages), linux-man

On Tue, Nov 12, 2019 at 9:51 PM Florian Weimer <fw@deneb.enyo.de> wrote:
>
> * enh:
>
> > no, because the C library has two choices when a thread exits:
> >
> > 1. unmap the thread.
> >
> > 2. keep the thread around for recycling.
> >
> > if you choose 1 (optimizing for space, like Android), your dereference
> > is illegal.
>
> This choice is only available for threads in a detached state.  For
> joinable threads, a conforming implementation cannot immediately
> deallocate all data structures on thread termination.  Among other
> things, it has to store the future return value of pthread_join
> somewhere.

ah, you're trying to say "signal 0 is potentially usable for a
joinable thread that's waiting to be joined"? that's true, but i'm not
sure how that's relevant to this patch. that wouldn't be an "invalid
thread ID" until it's joined.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [PATCH] pthread_kill.3: Update to match POSIX.
  2019-11-13  5:59                   ` enh
@ 2019-11-13  6:10                     ` Florian Weimer
  0 siblings, 0 replies; 12+ messages in thread
From: Florian Weimer @ 2019-11-13  6:10 UTC (permalink / raw)
  To: enh; +Cc: Michael Kerrisk \(man-pages\), linux-man

* enh:

> On Tue, Nov 12, 2019 at 9:51 PM Florian Weimer <fw@deneb.enyo.de> wrote:
>>
>> * enh:
>>
>> > no, because the C library has two choices when a thread exits:
>> >
>> > 1. unmap the thread.
>> >
>> > 2. keep the thread around for recycling.
>> >
>> > if you choose 1 (optimizing for space, like Android), your dereference
>> > is illegal.
>>
>> This choice is only available for threads in a detached state.  For
>> joinable threads, a conforming implementation cannot immediately
>> deallocate all data structures on thread termination.  Among other
>> things, it has to store the future return value of pthread_join
>> somewhere.
>
> ah, you're trying to say "signal 0 is potentially usable for a
> joinable thread that's waiting to be joined"? that's true, but i'm not
> sure how that's relevant to this patch. that wouldn't be an "invalid
> thread ID" until it's joined.

Correct.  That's POSIX's argument why ESRCH wouldn't be valid to
return here.  It's still a forceful loss of information, and
particularly annoying since POSIX doesn't specify pthread_tryjoin.

But I'm glad we've brought our discussion to a conclusion. 8-)

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, back to index

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-11-12 20:36 [PATCH] pthread_kill.3: Update to match POSIX enh
2019-11-12 21:38 ` Florian Weimer
2019-11-12 21:40   ` enh
2019-11-12 21:52     ` Florian Weimer
2019-11-12 22:06       ` enh
2019-11-12 22:11         ` Florian Weimer
2019-11-12 22:22           ` enh
2019-11-12 22:28             ` Florian Weimer
2019-11-13  5:27               ` enh
2019-11-13  5:51                 ` Florian Weimer
2019-11-13  5:59                   ` enh
2019-11-13  6:10                     ` Florian Weimer

Linux-man Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-man/0 linux-man/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-man linux-man/ https://lore.kernel.org/linux-man \
		linux-man@vger.kernel.org
	public-inbox-index linux-man

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-man


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git