New FAQ entry re why pthread_t is a struct

[Ross Johnson <Ross dot Johnson at homemail dot com dot au>]

Following the recent thread on this subject I've added a new entry to 
the FAQ and committed it to CVS. I've also updated the FAQ web page at 
http://sourceware.org/pthreads-win32/faq.html

Comments and suggestions welcome.

Regards.
Ross

Q 11    Why isn't pthread_t defined as a scalar (e.g. pointer or int)

       like it is for other POSIX threads implementations?

----

Originally pthread_t was defined as a pointer (to the opaque pthread_t_

struct) and later it was changed to a struct containing the original

pointer plus a sequence counter. This is allowed under both the original

POSIX Threads Standard and the current Single Unix Specification.

When pthread_t is a simple pointer to a struct some very difficult to

debug problems arise from the process of freeing and later allocing

thread structs because new pthread_t handles can acquire the identity of

previously detached threads. The change to a struct was made, along with

some changes to their internal managment, in order to guarantee (for

practical applications) that the pthread_t handle will be unique over the

life of the running process.

Where application code attempts to compare one pthread_t against another

directly, a compiler error will be emitted because structs can't be

compared at that level. This should signal a potentially serious problem

in the code design, which would go undetected if pthread_t was a scalar.

The POSIX Threading API provides a function named pthread_equal() to

compare pthread_t thread handles.

Other pthreads implementations, such as Sun's, use an int as the handle

but do guarantee uniqueness within the process scope. Win32 scalar typed

thread handles also guarantee uniqueness in system scope. It wasn't clear

how well the internal management of these handles would scale as the

number of threads and the fragmentation of the sequence numbering

increased for applications where thousands or millions of threads are

created and detached over time. The current management of threads within

pthreads-win32 using structs for pthread_t, and reusing without ever

freeing them, reduces the management time overheads to a constant, which

could be important given that pthreads-win32 threads are built on top of

Win32 threads and will therefore include that management overhead on top

of their own. The cost is that the memory resources used for thread

handles will remain at the peak level until the process exits.

While it may be inconvenient for developers to be forced away from making

assumptions about the internals of pthread_t, the advantage for the

future development of pthread-win32, as well as those applications that

use it and other pthread implementations, is that the library is free to

change pthread_t internals and management as better methods arise.