Added new Q11

1 files changed, 49 insertions, 1 deletions

diff --git a/FAQ b/FAQ
index 4f2d449..cb1786c 100644
--- a/FAQ
+++ b/FAQ
@@ -30,6 +30,9 @@ Q 9	Cancelation doesn't work for me, why?
 Q 10	How do I generate pthreadGCE.dll and libpthreadw32.a for use
 	with Mingw32?
 
+Q 11    Why isn't pthread_t defined as a scalar (e.g. pointer or int)
+        like it is for other POSIX threads implementations?
+
 =============================================================================
 
 Q 1	What is it?
@@ -400,4 +403,49 @@ This should not be a problem with recent versions of MinGW32.
 For early versions, see Thomas Pfaff's email at:
 http://sources.redhat.com/ml/pthreads-win32/2002/msg00000.html
 ------------------------------------------------------------------------------
- 
+
+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.
+