Re: [PATCH] pthread_kill.3: Update to match POSIX.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* enh:

> On Tue, Nov 12, 2019 at 1:52 PM Florian Weimer <fw@xxxxxxxxxxxxx> wrote:
>>
>> * enh:
>>
>> > On Tue, Nov 12, 2019 at 1:38 PM Florian Weimer <fw@xxxxxxxxxxxxx> 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.



[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux