Question regarding pthread_cancel and pthread_cond_timedwait

[Jakub Jelinek]

On Thu, Mar 24, 2005 at 11:03:36PM -0800, Eric Bruno wrote:
> We maintain internal thread exit status so I can skip cancelling the 
> threads which have succesfully exited. We normally just cancel 
> everything we started just
> as a big hammer to make sure every thread shuts down and exits.  We can 
> make the abort function a bit smarter since it has access to our 
> internal thread status if need be.
> 
> On the OS's I mentioned above 0 is returned on success, on failure:
> 
> On HP-UX  11.00 pthread_cancel returns the value ERSCH, errno is NOT set.
> 
> On Solaris SPARC and x86 same as HP-UX 11.00
> 
> AIX same as HP-UX an Solaris.
> 
> On Tru64 pthread_cancel returns EINVAL or ESRCH, errno is not set.

http://www.opengroup.org/onlinepubs/009695399/functions/pthread_cancel.html

    ERRORS

     The pthread_cancel() function may fail if:

     [ESRCH]
             No thread could be found corresponding to that specified by the given thread ID.

In NPTL, checking for invalid thread IDs is too costly, so there is just a
cheap test that covers a small subset of cases, but given the MAY above
this is allowed by the standard.
The reason is that in NPTL thread ID is a pointer to malloced memory, so
when the memory is freed (when the detached thread exits or when
a non-detached thread is pthread_join'ed), anything can happen.

This is not the only place where standard allows opaque cookies to
be implemented as indexes into some array (or hashes for hash tables),
or as pointers (where if you are using an invalid index, it can be usually
cheaply tested, while using stale pointers results in undefined behaviour).

Just avoid using invalid thread IDs and you should be fine.

	Jakub