On Mon, Jun 30, 2008 at 6:02 AM, Joerg Sonnenberger
<joerg@britannica.bec.de> wrote:
....
> Given that the interface requires you to validate the
> passed in pointer (you can *not* assume it is a valid value), it seems a
> lot more natural to return ESRCH.

I don't believe the above to be true. Indeed, the draft of the next
revision of SUS adds the following lines to the description of
pthread_join():

The behavior is undefined if the value specified by the thread argument
to pthread_join( ) does not refer to a joinable thread.

My recall of the discussion on the austin-group list was that this was
felt to be a clarification and not a change to the standard.


Hmm, I just noticed that the draft also adds the following to the
rationale section of the pthread_join() section:

If an implementation detects that the value specified by
the thread argument to pthread_join( ) does not refer to a
joinable thread, it is recommended that the function should
fail and report an [EINVAL] error.

If an implementation detects that the value specified by
the thread argument to pthread_join( ) refers to the calling
thread, it is recommended that the function should fail and
report an [EDEADLK] error.

If an implementation detects use of a thread ID after the
end of its lifetime, it is recommended that the function
should fail and report an [ESRCH] error.

So EINVAL is the right choice as far as the (next) standard is concerned.


Philip Guenther

On Mon, Jun 30, 2008 at 09:41:31AM -0600, Philip Guenther wrote:
> If an implementation detects use of a thread ID after the
> end of its lifetime, it is recommended that the function
> should fail and report an [ESRCH] error.
>
> So EINVAL is the right choice as far as the (next) standard is concerned.

This description for ESRCH would essentially mandate that libpthread
have to remember all thread ids ever used, otherwise it can't provide
consistent results. This is inconsistent with all existing
implementations.

It is interesting to compare libthr in FreeBSD with the older libkse and
libc_r. The return value of EINVAL for NULL is clearly a side effect of
the older joinable test. When they finally fixed the code to not
segfault on invalid thread id, they did not move the EINVAL for NULL.
As such I consider it a historic accident that it returns EINVAL for
NULL.

Joerg

On Tue, Jul 1, 2008 at 7:03 AM, Joerg Sonnenberger
<joerg@britannica.bec.de> wrote:
> On Mon, Jun 30, 2008 at 09:41:31AM -0600, Philip Guenther wrote:
>> If an implementation detects use of a thread ID after the
>> end of its lifetime, it is recommended that the function
>> should fail and report an [ESRCH] error.
>>
>> So EINVAL is the right choice as far as the (next) standard is concerned.
>
> This description for ESRCH would essentially mandate that libpthread
> have to remember all thread ids ever used, otherwise it can't provide
> consistent results. This is inconsistent with all existing
> implementations.

Hmm, Solaris 9 and 10 typedef pthread_t as unsigned int and assign
thread ids sequentially from 1 == original thread. pthread_join()
only returns EINVAL if the pthread_t names a thread that exists but is
detached. Otherwise it returns ESRCH. I'm not bored enough to see
how long it takes the Solaris boxes I have access to to create a 4
billion threads and wrap pthread_t.

For an implementation where pthread_t is a pointer, I don't think it
makes sense to ever return ESRCH. If you really pass an old pthread_t
value, the implementation will be chasing a freed pointer, so you're
already in undefined behavior.

<shurg>


Philip Guenther

On Tue, Jul 01, 2008 at 12:12:08PM -0600, Philip Guenther wrote:
> For an implementation where pthread_t is a pointer, I don't think it
> makes sense to ever return ESRCH. If you really pass an old pthread_t
> value, the implementation will be chasing a freed pointer, so you're
> already in undefined behavior.

NetBSD avoids that by using a red-black tree to find the pthread.
Not looking, but I guess that's exactly why glibc crashes here.
There are a number of places where the thread id might not be valid and
programming savely in libpthread is valuable for those.

Joerg