Merge remote-tracking branch 'origin/released'

* origin/released:
  Updated to latest CVS version of pthreads

Conflicts:
	pthreads/Makefile

1 files changed, 118 insertions, 42 deletions

diff --git a/pthreads/NEWS b/pthreads/NEWS
index 219fe4e23..44d3888a9 100644
--- a/pthreads/NEWS
+++ b/pthreads/NEWS
@@ -1,43 +1,119 @@
-CURRENT CVS HEAD Version
-RELEASE 2.9.0 pending
+RELEASE 2.10.0
+--------------
+(2099-99-99)
+
+General
+-------
+New bug fixes in all releases since 2.8.0 have NOT been applied to the
+1.x.x series.
+
+Some changes in CVS from 2011-02-26 onward may not be compatible with
+pre Windows 2000 systems.
+
+Testing and verification
+------------------------
+This version has been tested on SMP architecture (Intel x64 Hex Core)
+by completing the included test suite, as well as the stress and bench
+tests.
+
+Be sure to run your builds against the test suite. As of this release
+we are successfully passing the full test suite with all build
+configurations. If you see failures then please consider how your
+toolchains might be contributing to the failure. See the README file
+for more detailed descriptions of the toolchains and test systems that
+we have used to get the tests to pass successfully.
+
+New Features
+------------
+New routines:
+pthread_timedjoin_np()
+pthread_tryjoin_np()
+ - added for compatibility with Linux.
+sched_getaffinity()
+sched_setaffinity()
+pthread_getaffinity_np()
+pthread_getaffinity_np()
+ - added for compatibility with Linux and other libgcc-based systems.
+   The macros to manipulate cpu_set_t objects (the cpu affinity mask
+   vector) are also defined: CPU_ZERO, CPU_CLR, CPU_SET, CPU_EQUAL,
+   CPU_AND, CPU_OR, CPU_XOR, CPU_COUNT, CPU_ISSET.
+
+Builds:
+New makefile targets have been added and existing targets modified or
+removed. For example, targets to build and test all of the possible
+configurations of both dll and static libs.
+
+The makefiles now know how to build both 32 and 64 bit versions if
+the toolchain (MSVS or Mingw) allow it.
+
+Bug Fixes
+---------
+Small object file static linking now works. The autostatic.c code is
+required but nothing explicitly references this code so was getting
+optimised out.
+- Daniel Richard G.
+
+sem_getvalue() could return the errno value instead of setting errno
+and returning -1.
+- Ross Johnson
+
+Errno values were being lost if the library is statically linked
+with the runtime library, meaning also that the application used a
+separate runtime instance. This is still the case except a build
+switch has been added that allows more robust error status to be
+incorporated, i.e. allow the return code to be retrieved via
+GetLastError().
+- Daniel Richard G.
+
+Identified the cause of significant failures around cancelation
+and pthread_exit() for the GCE (GNU C++) build configuration as
+coming from Mingw32. Not sure if this is general or just when
+building 32 bit libraries and apps that run on 64 bit systems.
+These failures do not arise with Mingw64 32 bit builds running on
+64 bit systems.
+- Daniel Richard G. and Ross Johnson
+
+RELEASE 2.9.1
 -------------
-(2011-??-??)
+(2012-05-27)
 
 General
 -------
 New bug fixes in this release since 2.8.0 have NOT been applied to the
 1.x.x series.
 
-Version 2.8.0 may be the last release for some older Windows systems.
+This release replaces an extremely brief 2.9.0 release and adds
+some last minute non-code changes were made to embed better
+descriptive properties in the dlls to indicate target architecture
+and build environments.
+
 Some changes post 2011-02-26 in CVS may not be compatible with pre
 Windows 2000 systems.
 
-Version 1 no longer maintained
-------------------------------
-The 1.x.x series is no longer maintained. However, if you really need a
-version 1, the differences between 1.11.0 and 2.7.0 are very small, mainly
-revolving around the pthread_once_t_ struct. Those differences applied
-as a patch to the current 2.x.x should work. Don't forget to change
-the version numbering in pthread.h before building. If you distribute
-such a version 1.x.x please bear in mind that your numbers may clash
-with those of others doing the same thing. Please consider also making
-identifying changes in version.rc to differentiate your build.
+Use of other than the "C" version of the library is now discouraged.
+That is, the "C++" version fails some tests and does not provide any
+additional functionality.
 
 Testing and verification
 ------------------------
-The current CVS head version has been tested on an SMP architecture
-(AMD Phenom 9750 Quad Core) by running the MinGW32 (GCC) builds against
-the full test suite, stress tests and benchmarks.
+This version has been tested on SMP architecture (Intel x64 Hex Core)
+by completing the included test suite, stress and bench tests.
 
 New Features
 ------------
+DLL properties now properly includes the target architecture, i.e.
+right-click on the file pthreadVC2.dll in explorer and choose the Detail
+tab will show the compiler and architecture in the description field, e.g.
+"MS C x64" or "MS C x86".
+- Ross Johnson
+
 (MSC and GNU builds) The statically linked library now automatically
 initialises and cleans up on program start/exit, i.e. statically linked
 applications need not call the routines pthread_win32_process_attach_np()
 and pthread_win32_process_detach_np() explicitly. The per-thread routine
 pthread_win32_thread_detach_np() is also called at program exit to cleanup
-POSIX resources acquired by the primary Windows native thread (if I (RJ)
-understand the process correctly). Other Windows native threads that call
+POSIX resources acquired by the primary Windows native thread, if I (RJ)
+understand the process correctly. Other Windows native threads that call
 POSIX API routines may need to call the thread detach routine on thread
 exit if the application depends on reclaimed POSIX resources or running
 POSIX TSD (TLS) destructors.
@@ -449,7 +525,7 @@ Bugs fixed
 * pthread_setcancelstate() no longer checks for a pending
 async cancel event if the library is using alertable async
 cancel. See the README file (Prerequisites section) for info
-on adding alertable async cancelation.
+on adding alertable async cancellation.
 
 New features
 ------------
@@ -615,7 +691,7 @@ Bug fixes
 A segfault (memory access fault) will result, and no thread will be
 created.
 
-* pthread_barrier_wait() no longer acts as a cancelation point.
+* pthread_barrier_wait() no longer acts as a cancellation point.
 
 * Fix potential race condition in pthread_once()
 - Tristan Savatier  <tristan at mpegtv.com>
@@ -654,7 +730,7 @@ destruction/creation cycles.
 New tests
 ---------
 
-* semaphore4.c: Tests cancelation of the new sem_wait().
+* semaphore4.c: Tests cancellation of the new sem_wait().
 
 * semaphore4t.c: Likewise for sem_timedwait().
 
@@ -692,21 +768,21 @@ New features
 * Ported to AMD64.
 - Makoto Kato  <raven at oldskool.jp>
 
-* True pre-emptive asynchronous cancelation of threads. This is optional
+* True pre-emptive asynchronous cancellation of threads. This is optional
 and requires that Panagiotis E. Hadjidoukas's QueueUserAPCEx package be
 installed. This package is included in the pthreads-win32 self-unpacking
 Zip archive starting from this snapshot. See the README.txt file inside
 the package for installation details.
 
-Note: If you don't use async cancelation in your application, or don't need
+Note: If you don't use async cancellation in your application, or don't need
 to cancel threads that are blocked on system resources such as network I/O,
-then the default non-preemptive async cancelation is probably good enough.
+then the default non-preemptive async cancellation is probably good enough.
 However, pthreads-win32 auto-detects the availability of these components
 at run-time, so you don't need to rebuild the library from source if you
 change your mind later.
 
 All of the advice available in books and elsewhere on the undesirability
-of using async cancelation in any application still stands, but this
+of using async cancellation in any application still stands, but this
 feature is a welcome addition with respect to the library's conformance to
 the POSIX standard.
 
@@ -735,12 +811,12 @@ SNAPSHOT 2003-09-04
 
 Bug fixes
 ---------
-* ptw32_cancelableWait() now allows cancelation of waiting implicit POSIX
+* ptw32_cancelableWait() now allows cancellation of waiting implicit POSIX
 threads.
 
 New test
 --------
-* cancel8.c tests cancelation of Win32 threads waiting at a POSIX cancelation
+* cancel8.c tests cancellation of Win32 threads waiting at a POSIX cancellation
 point.
 
 
@@ -755,13 +831,13 @@ DuplicateHandle failed instead of recycle it (very unlikely).
 * pthread_exit() was neither freeing nor recycling the POSIX thread struct
 for implicit POSIX threads.
 
-New feature - Cancelation of/by Win32 (non-POSIX) threads
+New feature - cancellation of/by Win32 (non-POSIX) threads
 ---------------------------------------------------------
 Since John Bossom's original implementation, the library has allowed non-POSIX
 initialised threads (Win32 threads) to call pthreads-win32 routines and
 therefore interact with POSIX threads. This is done by creating an on-the-fly
 POSIX thread ID for the Win32 thread that, once created, allows fully
-reciprical interaction. This did not extend to thread cancelation (async or
+reciprical interaction. This did not extend to thread cancellation (async or
 deferred). Now it does.
 
 Any thread can be canceled by any other thread (Win32 or POSIX) if the former
@@ -771,15 +847,15 @@ PTHREAD_CANCELED (retrieved with GetExitCodeThread()).
 
 This allows a Win32 thread to, for example, call POSIX CV routines in the same way
 that POSIX threads would/should, with pthread_cond_wait() cancelability and
-cleanup handlers (pthread_cond_wait() is a POSIX cancelation point).
+cleanup handlers (pthread_cond_wait() is a POSIX cancellation point).
 
-By adding cancelation, Win32 threads should now be able to call all POSIX
+By adding cancellation, Win32 threads should now be able to call all POSIX
 threads routines that make sense including semaphores, mutexes, condition
 variables, read/write locks, barriers, spinlocks, tsd, cleanup push/pop,
-cancelation, pthread_exit, scheduling, etc.
+cancellation, pthread_exit, scheduling, etc.
 
 Note that these on-the-fly 'implicit' POSIX thread IDs are initialised as detached
-(not joinable) with deferred cancelation type. The POSIX thread ID will be created
+(not joinable) with deferred cancellation type. The POSIX thread ID will be created
 automatically by any POSIX routines that need a POSIX handle (unless the routine
 needs a pthread_t as a parameter of course). A Win32 thread can discover it's own
 POSIX thread ID by calling pthread_self(), which will create the handle if
@@ -844,7 +920,7 @@ Bug fixes
 
 * pthread_mutex_trylock() now returns correct error values.
 pthread_mutex_destroy() will no longer destroy a recursively locked mutex.
-pthread_mutex_lock() is no longer inadvertantly behaving as a cancelation point.
+pthread_mutex_lock() is no longer inadvertantly behaving as a cancellation point.
 - Thomas Pfaff  <tpfaff@gmx.net>
 
 * pthread_mutex_timedlock() no longer occasionally sets incorrect mutex
@@ -892,7 +968,7 @@ from the compiler/language, and one of the following was defined accordingly:
         __CLEANUP_C             C, including GNU GCC, not MSVC
 
 These defines determine the style of cleanup (see pthread.h) and,
-most importantly, the way that cancelation and thread exit (via
+most importantly, the way that cancellation and thread exit (via
 pthread_exit) is performed (see the routine ptw32_throw() in private.c).
 
 In short, the exceptions versions of the library throw an exception
@@ -904,7 +980,7 @@ is when it's canceled or exits via pthread_exit().
 In this and future snapshots, unless the build explicitly defines (e.g.
 via a compiler option) __CLEANUP_SEH, __CLEANUP_CXX, or __CLEANUP_C, then
 the build NOW always defaults to __CLEANUP_C style cleanup. This style
-uses setjmp/longjmp in the cancelation and pthread_exit implementations,
+uses setjmp/longjmp in the cancellation and pthread_exit implementations,
 and therefore won't do stack unwinding even when linked to applications
 that have it (e.g. C++ apps). This is for consistency with most
 current commercial Unix POSIX threads implementations. Compaq's TRU64
@@ -1100,9 +1176,9 @@ with the C version, but AFAIK cleanup handlers would not then run in the
 correct sequence with destructors and exception cleanup handlers when
 an exception occurs.
 
-* Cancelation once started in a thread cannot now be inadvertantly
-double canceled. That is, once a thread begins it's cancelation run,
-cancelation is disabled and a subsequent cancel request will
+* cancellation once started in a thread cannot now be inadvertantly
+double canceled. That is, once a thread begins it's cancellation run,
+cancellation is disabled and a subsequent cancel request will
 return an error (ESRCH).
 
 * errno: An incorrect compiler directive caused a local version
@@ -1150,7 +1226,7 @@ SNAPSHOT 2000-08-10
 -------------------
 
 New:
--       asynchronous cancelation on X86 (Jason Nye)
+-       asynchronous cancellation on X86 (Jason Nye)
 -       Makefile compatible with MS nmake to replace
         buildlib.bat
 -       GNUmakefile for Mingw32
@@ -1190,7 +1266,7 @@ Some new tests have been added.
 SNAPSHOT 1999-10-17
 -------------------
 
-Bug fix - Cancelation of threads waiting on condition variables
+Bug fix - cancellation of threads waiting on condition variables
 now works properly (Lorin Hochstein and Peter Slacik)