cvs update pthreads

1 files changed, 1187 insertions, 1110 deletions

diff --git a/pthreads/NEWS b/pthreads/NEWS
index 18fe54325..f713955fe 100644
--- a/pthreads/NEWS
+++ b/pthreads/NEWS
@@ -1,1110 +1,1187 @@
-RELEASE 2.8.0
--------------
-(2006-12-22)
-
-General
--------
-New bug fixes in this release since 2.7.0 have not been applied to the
-version 1.x.x series. It is probably time to drop version 1.
-
-Testing and verification
-------------------------
-This release has not yet been tested on SMP architechtures. All tests pass
-on a uni-processor system.
-
-Bug fixes
----------
-Sem_destroy could return EBUSY even though no threads were waiting on the 
-semaphore. Other races around invalidating semaphore structs (internally)
-have been removed as well.
-
-New tests
----------
-semaphore5.c - tests the bug fix referred to above.
-
-
-RELEASE 2.7.0
--------------
-(2005-06-04)
-
-General
--------
-All new features in this release have been back-ported in release 1.11.0,
-including the incorporation of MCS locks in pthread_once, however, versions
-1 and 2 remain incompatible even though they are now identical in
-performance and functionality.
-
-Testing and verification
-------------------------
-This release has been tested (passed the test suite) on both uni-processor
-and multi-processor systems.
-- Tim Theisen
-
-Bug fixes
----------
-Pthread_once has been re-implemented to remove priority boosting and other
-complexity to improve robustness. Races for Win32 handles that are not
-recycle-unique have been removed. The general form of pthread_once is now
-the same as that suggested earlier by Alexander Terekhov, but instead of the
-'named mutex', a queue-based lock has been implemented which has the required
-properties of dynamic self initialisation and destruction. This lock is also
-efficient. The ABI is unaffected in as much as the size of pthread_once_t has
-not changed and PTHREAD_ONCE_INIT has not changed, however, applications that
-peek inside pthread_once_t, which is supposed to be opaque, will break.
-- Vladimir Kliatchko
-
-New features
-------------
-* Support for Mingw cross development tools added to GNUmakefile.
-Mingw cross tools allow building the libraries on Linux.
-- Mikael Magnusson
-
-
-RELEASE 2.6.0
--------------
-(2005-05-19)
-
-General
--------
-All of the bug fixes and new features in this release have been
-back-ported in release 1.10.0.
-
-Testing and verification
-------------------------
-This release has been tested (passed the test suite) on both uni-processor
-and multi-processor systems. Thanks to Tim Theisen at TomoTherapy for
-exhaustively running the MP tests and for providing crutial observations
-and data when faults are detected.
-
-Bugs fixed
-----------
-
-* pthread_detach() now reclaims remaining thread resources if called after
-the target thread has terminated. Previously, this routine did nothing in
-this case.
-
-New tests
----------
-
-* detach1.c - tests that pthread_detach properly invalidates the target
-thread, which indicates that the thread resources have been reclaimed.
-
-
-RELEASE 2.5.0
--------------
-(2005-05-09)
-
-General
--------
-
-The package now includes a reference documentation set consisting of
-HTML formatted Unix-style manual pages that have been edited for
-consistency with Pthreads-w32. The set can also be read online at:
-http://sources.redhat.com/pthreads-win32/manual/index.html
-
-Thanks again to Tim Theisen for running the test suite pre-release
-on an MP system.
-
-All of the bug fixes and new features in this release have been
-back-ported in release 1.9.0.
-
-Bugs fixed
-----------
-
-* Thread Specific Data (TSD) key management has been ammended to
-eliminate a source of (what was effectively) resource leakage (a HANDLE
-plus memory for each key destruct routine/thread association). This was
-not a true leak because these resources were eventually reclaimed when
-pthread_key_delete was run AND each thread referencing the key had exited.
-The problem was that these two conditions are often not met until very
-late, and often not until the process is about to exit.
-
-The ammended implementation avoids the need for the problematic HANDLE
-and reclaims the memory as soon as either the key is deleted OR the
-thread exits, whichever is first.
-
-Thanks to Richard Hughes at Aculab for identifying and locating the leak.
-
-* TSD key destructors are now processed up to PTHREAD_DESTRUCTOR_ITERATIONS
-times instead of just once. PTHREAD_DESTRUCTOR_ITERATIONS has been
-defined in pthread.h for some time but not used.
-
-* Fix a semaphore accounting race between sem_post/sem_post_multiple
-and sem_wait cancellation. This is the same issue as with
-sem_timedwait that was fixed in the last release.
-
-* sem_init, sem_post, and sem_post_multiple now check that the
-semaphore count never exceeds _POSIX_SEM_VALUE_MAX.
-
-* Although sigwait() is nothing more than a no-op, it should at least
-be a cancellation point to be consistent with the standard.
-
-New tests
----------
-
-* stress1.c - attempts to expose problems in condition variable
-and semaphore timed wait logic. This test was inspired by Stephan
-Mueller's sample test code used to identify the sem_timedwait bug
-from the last release. It's not a part of the regular test suite
-because it can take awhile to run. To run it:
-nmake clean VC-stress
-
-* tsd2.c - tests that key destructors are re-run if the tsd key value is
-not NULL after the destructor routine has run. Also tests that
-pthread_setspecific() and pthread_getspecific() are callable from
-destructors.
-
-
-RELEASE 2.4.0
--------------
-(2005-04-26)
-
-General
--------
-
-There is now no plan to release a version 3.0.0 to fix problems in
-pthread_once(). Other possible implementations of pthread_once
-will still be investigated for a possible future release in an attempt
-to reduce the current implementation's complexity.
-
-All of the bug fixes and new features in this release have been
-back-ported for release 1.8.0.
-
-Bugs fixed
-----------
-
-* Fixed pthread_once race (failures on an MP system). Thanks to
-Tim Theisen for running exhaustive pre-release testing on his MP system
-using a range of compilers:
-  VC++ 6
-  VC++ 7.1
-  Intel C++ version 8.0
-All tests passed.
-Some minor speed improvements were also done.
-
-* Fix integer overrun error in pthread_mutex_timedlock() - missed when
-sem_timedwait() was fixed in release 2.2.0. This routine no longer returns
-ENOTSUP when NEED_SEM is defined - it is supported (NEED_SEM is only
-required for WinCE versions prior to 3.0).
-
-* Fix timeout bug in sem_timedwait().
-- Thanks to Stephan Mueller for reporting, providing diagnostic output
-and test code.
-
-* Fix several problems in the NEED_SEM conditionally included code.
-NEED_SEM included code is provided for systems that don't implement W32
-semaphores, such as WinCE prior to version 3.0. An alternate implementation
-of POSIX semaphores is built using W32 events for these systems when
-NEED_SEM is defined. This code has been completely rewritten in this
-release to reuse most of the default POSIX semaphore code, and particularly,
-to implement all of the sem_* routines supported by pthreads-win32. Tim
-Theisen also run the test suite over the NEED_SEM code on his MP system. All
-tests passed.
-
-* The library now builds without errors for the Borland Builder 5.5 compiler.
-
-New features
-------------
-
-* pthread_mutex_timedlock() and all sem_* routines provided by
-pthreads-win32 are now implemented for WinCE versions prior to 3.0. Those
-versions did not implement W32 semaphores. Define NEED_SEM in config.h when
-building the library for these systems.
-
-Known issues in this release
-----------------------------
-
-* pthread_once is too complicated - but it works as far as testing can
-determine..
-
-* The Borland version of the dll fails some of the tests with a memory read
-exception. The cause is not yet known but a compiler bug has not been ruled
-out.
-
-
-RELEASE 2.3.0
--------------
-(2005-04-12)
-
-General
--------
-
-Release 1.7.0 is a backport of features and bug fixes new in
-this release. See earlier notes under Release 2.0.0/General.
-
-Bugs fixed
-----------
-
-* Fixed pthread_once potential for post once_routine cancellation
-hanging due to starvation. See comments in pthread_once.c.
-Momentary priority boosting is used to ensure that, after a
-once_routine is cancelled, the thread that will run the
-once_routine is not starved by higher priority waiting threads at
-critical times. Priority boosting occurs only AFTER a once_routine 
-cancellation, and is applied only to that once_control. The
-once_routine is run at the thread's normal base priority.
-
-New tests
----------
-
-* once4.c: Aggressively tests pthread_once() under realtime
-conditions using threads with varying priorities. Windows'
-random priority boosting does not occur for threads with realtime
-priority levels.
-
-
-RELEASE 2.2.0
--------------
-(2005-04-04)
-
-General
--------
-
-* Added makefile targets to build static link versions of the library.
-Both MinGW and MSVC. Please note that this does not imply any change
-to the LGPL licensing, which still imposes psecific conditions on
-distributing software that has been statically linked with this library.
-
-* There is a known bug in pthread_once(). Cancellation of the init_routine
-exposes a potential starvation (i.e. deadlock) problem if a waiting thread
-has a higher priority than the initting thread. This problem will be fixed
-in version 3.0.0 of the library.
-
-Bugs fixed
-----------
-
-* Fix integer overrun error in sem_timedwait().
-Kevin Lussier
-
-* Fix preprocessor directives for static linking.
-Dimitar Panayotov
-
-
-RELEASE 2.1.0
--------------
-(2005-03-16)
-
-Bugs fixed
-----------
-
-* Reverse change to pthread_setcancelstate() in 2.0.0.
-
-
-RELEASE 2.0.0
--------------
-(2005-03-16)
-
-General
--------
-
-This release represents an ABI change and the DLL version naming has
-incremented from 1 to 2, e.g. pthreadVC2.dll.
-
-Version 1.4.0 back-ports the new functionality included in this
-release. Please distribute DLLs built from that version with updates
-to applications built on pthreads-win32 version 1.x.x.
-
-The package naming has changed, replacing the snapshot date with 
-the version number + descriptive information. E.g. this
-release is "pthreads-w32-2-0-0-release".
-
-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.
-
-New features
-------------
-
-* pthread_once() now supports init_routine cancellability.
-
-New tests
----------
-
-* Agressively test pthread_once() init_routine cancellability.
-
-
-SNAPSHOT 2005-03-08
--------------------
-Version 1.3.0
-
-Bug reports (fixed)
--------------------
-
-* Implicitly created threads leave Win32 handles behind after exiting.
-- Dmitrii Semii
-
-* pthread_once() starvation problem.
-- Gottlob Frege
-
-New tests
----------
-
-* More intense testing of pthread_once().
-
-
-SNAPSHOT 2005-01-25
--------------------
-Version 1.2.0
-
-Bug fixes
----------
-
-* Attempted acquisition of a recursive mutex could cause waiting threads
-to not be woken when the mutex was released.
-- Ralf Kubis  <RKubis at mc.com>
-
-* Various package omissions have been fixed.
-
-
-SNAPSHOT 2005-01-03
--------------------
-Version 1.1.0
-
-Bug fixes
----------
-
-* Unlocking recursive or errorcheck mutexes would sometimes
-unexpectedly return an EPERM error (bug introduced in
-snapshot-2004-11-03).
-- Konstantin Voronkov  <beowinkle at yahoo.com>
-
-
-SNAPSHOT 2004-11-22
--------------------
-Version 1.0.0
-
-This snapshot primarily fixes the condvar bug introduced in
-snapshot-2004-11-03. DLL versioning has also been included to allow
-applications to runtime check the Microsoft compatible DLL version
-information, and to extend the DLL naming system for ABI and major
-(non-backward compatible) API changes. See the README file for details.
-
-Bug fixes
----------
-
-* Condition variables no longer deadlock (bug introduced in
-snapshot-2004-11-03).
-- Alexander Kotliarov and Nicolas at saintmac
-
-* DLL naming extended to avoid 'DLL hell' in the future, and to
-accommodate the ABI change introduced in snapshot-2004-11-03. Snapshot
-2004-11-03 will be removed from FTP sites.
-
-New features
-------------
-
-* A Microsoft-style version resource has been added to the DLL for
-applications that wish to check DLL compatibility at runtime.
-
-* Pthreads-win32 DLL naming has been extended to allow incompatible DLL
-versions to co-exist in the same filesystem. See the README file for details,
-but briefly: while the version information inside the DLL will change with
-each release from now on, the DLL version names will only change if the new
-DLL is not backward compatible with older applications.
-
-The versioning scheme has been borrowed from GNU Libtool, and the DLL
-naming scheme is from Cygwin. Provided the Libtool-style numbering rules are
-honoured, the Cygwin DLL naming scheme automatcally ensures that DLL name
-changes are minimal and that applications will not load an incompatible
-pthreads-win32 DLL.
-
-Those who use the pre-built DLLs will find that the DLL/LIB names have a new
-suffix (1) in this snapshot. E.g. pthreadVC1.dll etc.
-
-* The POSIX thread ID reuse uniqueness feature introduced in the last snapshot
-has been kept as default, but the behaviour can now be controlled when the DLL
-is built to effectively switch it off. This makes the library much more
-sensitive to applications that assume that POSIX thread IDs are unique, i.e.
-are not strictly compliant with POSIX. See the PTW32_THREAD_ID_REUSE_INCREMENT
-macro comments in config.h for details.
-
-Other changes
--------------
-Certain POSIX macros have changed.
-
-These changes are intended to conform to the Single Unix Specification version 3,
-which states that, if set to 0 (zero) or not defined, then applications may use
-sysconf() to determine their values at runtime. Pthreads-win32 does not
-implement sysconf().
-
-The following macros are no longer undefined, but defined and set to -1
-(not implemented):
-
-      _POSIX_THREAD_ATTR_STACKADDR
-      _POSIX_THREAD_PRIO_INHERIT
-      _POSIX_THREAD_PRIO_PROTECT
-      _POSIX_THREAD_PROCESS_SHARED
-
-The following macros are defined and set to 200112L (implemented):
-
-      _POSIX_THREADS
-      _POSIX_THREAD_SAFE_FUNCTIONS
-      _POSIX_THREAD_ATTR_STACKSIZE
-      _POSIX_THREAD_PRIORITY_SCHEDULING
-      _POSIX_SEMAPHORES
-      _POSIX_READER_WRITER_LOCKS
-      _POSIX_SPIN_LOCKS
-      _POSIX_BARRIERS
-
-The following macros are defined and set to appropriate values:
-
-      _POSIX_THREAD_THREADS_MAX
-      _POSIX_SEM_VALUE_MAX
-      _POSIX_SEM_NSEMS_MAX
-      PTHREAD_DESTRUCTOR_ITERATIONS
-      PTHREAD_KEYS_MAX
-      PTHREAD_STACK_MIN
-      PTHREAD_THREADS_MAX
-
-
-SNAPSHOT 2004-11-03
--------------------
-
-DLLs produced from this snapshot cannot be used with older applications without
-recompiling the application, due to a change to pthread_t to provide unique POSIX
-thread IDs.
-
-Although this snapshot passes the extended test suite, many of the changes are
-fairly major, and some applications may show different behaviour than previously,
-so adopt with care. Hopefully, any changed behaviour will be due to the library
-being better at it's job, not worse.
-
-Bug fixes
----------
-
-* pthread_create() no longer accepts NULL as the thread reference arg.
-A segfault (memory access fault) will result, and no thread will be
-created.
-
-* pthread_barrier_wait() no longer acts as a cancelation point.
-
-* Fix potential race condition in pthread_once()
-- Tristan Savatier  <tristan at mpegtv.com>
-
-* Changes to pthread_cond_destroy() exposed some coding weaknesses in several
-test suite mini-apps because pthread_cond_destroy() now returns EBUSY if the CV
-is still in use.
-
-New features
-------------
-
-* Added for compatibility:
-PTHREAD_RECURSIVE_MUTEX_INITIALIZER,
-PTHREAD_ERRORCHECK_MUTEX_INITIALIZER,
-PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP,
-PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP
-
-* Initial support for Digital Mars compiler
-- Anuj Goyal  <anuj.goyal at gmail.com>
-
-* Faster Mutexes. These have been been rewritten following a model provided by
-Alexander Terekhov that reduces kernel space checks, and eliminates some additional
-critical sections used to manage a race between timedlock expiration and unlock.
-Please be aware that the new mutexes do not enforce strict absolute FIFO scheduling
-of mutexes, however any out-of-order lock acquisition should be very rare.
-
-* Faster semaphores. Following a similar model to mutexes above, these have been
-rewritten to use preliminary users space checks.
-
-* sem_getvalue() now returns the number of waiters.
-
-* The POSIX thread ID now has much stronger uniqueness characteristics. The library
-garrantees not to reuse the same thread ID for at least 2^(wordsize) thread
-destruction/creation cycles.
-
-New tests
----------
-
-* semaphore4.c: Tests cancelation of the new sem_wait().
-
-* semaphore4t.c: Likewise for sem_timedwait().
-
-* rwlock8.c: Tests and times the slow execution paths of r/w locks, and the CVs,
-mutexes, and semaphores that they're built on.
-
-
-SNAPSHOT 2004-05-16
--------------------
-
-Attempt to add Watcom to the list of compilers that can build the library.
-This failed in the end due to it's non-thread-aware errno. The library
-builds but the test suite fails. See README.Watcom for more details.
-
-Bug fixes
----------
-* Bug and memory leak in sem_init()
-- Alex Blanco  <Alex.Blanco at motorola.com>
-
-* ptw32_getprocessors() now returns CPU count of 1 for WinCE.
-- James Ewing  <james.ewing at sveasoft.com>
-
-* pthread_cond_wait() could be canceled at a point where it should not
-be cancelable. Fixed.
-- Alexander Terekhov  <TEREKHOV at de.ibm.com>
-
-* sem_timedwait() had an incorrect timeout calculation.
-- Philippe Di Cristo  <philipped at voicebox.com>
-
-* Fix a memory leak left behind after threads are destroyed.
-- P. van Bruggen  <pietvb at newbridges.nl>
-
-New features
-------------
-* Ported to AMD64.
-- Makoto Kato  <raven at oldskool.jp>
-
-* True pre-emptive asynchronous cancelation 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
-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.
-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
-feature is a welcome addition with respect to the library's conformance to
-the POSIX standard.
-
-SNAPSHOT 2003-09-18
--------------------
-
-Cleanup of thread priority management. In particular, setting of thread
-priority now attempts to map invalid Win32 values within the range returned
-by sched_get_priority_min/max() to useful values. See README.NONPORTABLE
-under "Thread priority".
-
-Bug fixes
----------
-* pthread_getschedparam() now returns the priority given by the most recent
-call to pthread_setschedparam() or established by pthread_create(), as
-required by the standard. Previously, pthread_getschedparam() incorrectly
-returned the running thread priority at the time of the call, which may have
-been adjusted or temporarily promoted/demoted.
-
-* sched_get_priority_min() and sched_get_priority_max() now return -1 on error
-and set errno. Previously, they incorrectly returned the error value directly.
-
-
-SNAPSHOT 2003-09-04
--------------------
-
-Bug fixes
----------
-* ptw32_cancelableWait() now allows cancelation of waiting implicit POSIX
-threads.
-
-New test
---------
-* cancel8.c tests cancelation of Win32 threads waiting at a POSIX cancelation
-point.
-
-
-SNAPSHOT 2003-09-03
--------------------
-
-Bug fixes
----------
-* pthread_self() would free the newly created implicit POSIX thread handle if
-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
----------------------------------------------------------
-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
-deferred). Now it does.
-
-Any thread can be canceled by any other thread (Win32 or POSIX) if the former
-thread's POSIX pthread_t value is known. It's TSD destructors and POSIX
-cleanup handlers will be run before the thread exits with an exit code of
-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).
-
-By adding cancelation, 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.
-
-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
-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
-necessary and return the pthread_t value.
-
-New tests
----------
-Test the above new feature.
-
-
-SNAPSHOT 2003-08-19
--------------------
-
-This snapshot fixes some accidental corruption to new test case sources.
-There are no changes to the library source code.
-
-
-SNAPSHOT 2003-08-15
--------------------
-
-Bug fixes
----------
-
-* pthread.dsp now uses correct compile flags (/MD).
-- Viv  <vcotirlea@hotmail.com>
-
-* pthread_win32_process_detach_np() fixed memory leak.
-- Steven Reddie  <Steven.Reddie@ca.com>
-
-* pthread_mutex_destroy() fixed incorrect return code.
-- Nicolas Barry  <boozai@yahoo.com>
-
-* pthread_spin_destroy() fixed memory leak.
-- Piet van Bruggen  <pietvb@newbridges.nl>
-
-* Various changes to tighten arg checking, and to work with later versions of
-MinGW32 and MsysDTK.
-
-* pthread_getschedparam() etc, fixed dangerous thread validity checking.
-- Nicolas Barry  <boozai@yahoo.com>
-
-* POSIX thread handles are now reused and their memory is not freed on thread exit.
-This allows for stronger thread validity checking.
-
-New standard routine
---------------------
-
-* pthread_kill() added to provide thread validity checking to applications.
-It does not accept any non zero values for the signal arg.
-
-New test cases
---------------
-
-* New test cases to confirm validity checking, pthread_kill(), and thread reuse.
-
-
-SNAPSHOT 2003-05-10
--------------------
-
-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.
-- Thomas Pfaff  <tpfaff@gmx.net>
-
-* pthread_mutex_timedlock() no longer occasionally sets incorrect mutex
-ownership, causing deadlocks in some applications.
-- Robert Strycek <strycek@posam.sk> and Alexander Terekhov  <TEREKHOV@de.ibm.com>
-
-
-SNAPSHOT 2002-11-04
--------------------
-
-Bug fixes
----------
-
-* sem_getvalue() now returns the correct value under Win NT and WinCE.
-- Rob Fanner  <rfanner@stonethree.com>
-
-* sem_timedwait() now uses tighter checks for unreasonable
-abstime values - that would result in unexpected timeout values.
-
-* ptw32_cond_wait_cleanup() no longer mysteriously consumes
-CV signals but may produce more spurious wakeups. It is believed
-that the sem_timedwait() call is consuming a CV signal that it
-shouldn't.
-- Alexander Terekhov  <TEREKHOV@de.ibm.com>
-
-* Fixed a memory leak in ptw32_threadDestroy() for implicit threads.
-
-* Fixed potential for deadlock in pthread_cond_destroy().
-A deadlock could occur for statically declared CVs (PTHREAD_COND_INITIALIZER),
-when one thread is attempting to destroy the condition variable while another
-is attempting to dynamically initialize it.
-- Michael Johnson  <michaelj@maine.rr.com>
-
-
-SNAPSHOT 2002-03-02
--------------------
-
-Cleanup code default style. (IMPORTANT)
-----------------------------------------------------------------------
-Previously, if not defined, the cleanup style was determined automatically
-from the compiler/language, and one of the following was defined accordingly:
-
-        __CLEANUP_SEH   MSVC only
-        __CLEANUP_CXX   C++, including MSVC++, GNU G++
-        __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
-pthread_exit) is performed (see the routine ptw32_throw() in private.c).
-
-In short, the exceptions versions of the library throw an exception
-when a thread is canceled or exits (via pthread_exit()), which is
-caught by a handler in the thread startup routine, so that the
-the correct stack unwinding occurs regardless of where the thread
-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,
-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
-may be an exception (no pun intended) and possible future trend.
-
-Although it was not clearly documented before, it is still necessary to
-build your application using the same __CLEANUP_* define as was
-used for the version of the library that you link with, so that the
-correct parts of pthread.h are included. That is, the possible
-defines require the following library versions:
-
-        __CLEANUP_SEH   pthreadVSE.dll
-        __CLEANUP_CXX   pthreadVCE.dll or pthreadGCE.dll
-        __CLEANUP_C     pthreadVC.dll or pthreadGC.dll
-
-E.g. regardless of whether your app is C or C++, if you link with
-pthreadVC.lib or libpthreadGC.a, then you must define __CLEANUP_C.
-
-
-THE POINT OF ALL THIS IS: if you have not been defining one of these
-explicitly, then the defaults as described at the top of this
-section were being used.
-
-THIS NOW CHANGES, as has been explained above, but to try to make this
-clearer here's an example:
-
-If you were building your application with MSVC++ i.e. using C++
-exceptions and not explicitly defining one of __CLEANUP_*, then
-__CLEANUP_C++ was automatically defined for you in pthread.h.
-You should have been linking with pthreadVCE.dll, which does
-stack unwinding.
-
-If you now build your application as you had before, pthread.h will now
-automatically set __CLEANUP_C as the default style, and you will need to
-link with pthreadVC.dll. Stack unwinding will now NOT occur when a thread
-is canceled, or the thread calls pthread_exit().
-
-Your application will now most likely behave differently to previous
-versions, and in non-obvious ways. Most likely is that locally
-instantiated objects may not be destroyed or cleaned up after a thread
-is canceled.
-
-If you want the same behaviour as before, then you must now define
-__CLEANUP_C++ explicitly using a compiler option and link with
-pthreadVCE.dll as you did before.
-
-
-WHY ARE WE MAKING THE DEFAULT STYLE LESS EXCEPTION-FRIENDLY?
-Because no commercial Unix POSIX threads implementation allows you to
-choose to have stack unwinding. Therefore, providing it in pthread-win32
-as a default is dangerous. We still provide the choice but unless
-you consciously choose to do otherwise, your pthreads applications will
-now run or crash in similar ways irrespective of the threads platform
-you use. Or at least this is the hope.
-
-
-WHY NOT REMOVE THE EXCEPTIONS VERSIONS OF THE LIBRARY ALTOGETHER?
-There are a few reasons:
-- because there are well respected POSIX threads people who believe
-  that POSIX threads implementations should be exceptions aware and
-  do the expected thing in that context. (There are equally respected
-  people who believe it should not be easily accessible, if it's there
-  at all, for unconditional conformity to other implementations.)
-- because pthreads-win32 is one of the few implementations that has
-  the choice, perhaps the only freely available one, and so offers
-  a laboratory to people who may want to explore the effects;
-- although the code will always be around somewhere for anyone who
-  wants it, once it's removed from the current version it will not be
-  nearly as visible to people who may have a use for it.
-
-
-Source module splitting
------------------------
-In order to enable smaller image sizes to be generated
-for applications that link statically with the library,
-most routines have been separated out into individual
-source code files.
-
-This is being done in such a way as to be backward compatible.
-The old source files are reused to congregate the individual
-routine files into larger translation units (via a bunch of
-# includes) so that the compiler can still optimise wherever
-possible, e.g. through inlining, which can only be done
-within the same translation unit.
-
-It is also possible to build the entire library by compiling
-the single file named "pthread.c", which just #includes all
-the secondary congregation source files. The compiler
-may be able to use this to do more inlining of routines.
-
-Although the GNU compiler is able to produce libraries with
-the necessary separation (the -ffunction-segments switch),
-AFAIK, the MSVC and other compilers don't have this feature.
-
-Finally, since I use makefiles and command-line compilation,
-I don't know what havoc this reorganisation may wreak amongst
-IDE project file users. You should be able to continue
-using your existing project files without modification.
-
-
-New non-portable functions
---------------------------
-pthread_num_processors_np():
-  Returns the number of processors in the system that are
-  available to the process, as determined from the processor
-  affinity mask.
-
-pthread_timechange_handler_np():
-  To improve tolerance against operator or time service initiated
-  system clock changes.
-
-  This routine can be called by an application when it
-  receives a WM_TIMECHANGE message from the system. At present
-  it broadcasts all condition variables so that waiting threads
-  can wake up and re-evaluate their conditions and restart
-  their timed waits if required.
-  - Suggested by Alexander Terekhov
-
-
-Platform dependence
--------------------
-As Win95 doesn't provide one, the library now contains
-it's own InterlockedCompareExchange() routine, which is used
-whenever Windows doesn't provide it. InterlockedCompareExchange()
-is used to implement spinlocks and barriers, and also in mutexes.
-This routine relies on the CMPXCHG machine instruction which
-is not available on i386 CPUs. This library (from snapshot
-20010712 onwards) is therefore no longer supported on i386
-processor platforms.
-
-
-New standard routines
----------------------
-For source code portability only - rwlocks cannot be process shared yet.
-
-        pthread_rwlockattr_init()
-        pthread_rwlockattr_destroy()
-        pthread_rwlockattr_setpshared()
-        pthread_rwlockattr_getpshared()
-
-As defined in the new POSIX standard, and the Single Unix Spec version 3:
-
-        sem_timedwait()
-        pthread_mutex_timedlock()    - Alexander Terekhov and Thomas Pfaff
-        pthread_rwlock_timedrdlock() - adapted from pthread_rwlock_rdlock()
-        pthread_rwlock_timedwrlock() - adapted from pthread_rwlock_wrlock()
-
-
-pthread.h no longer includes windows.h
---------------------------------------
-[Not yet for G++]
-
-This was done to prevent conflicts.
-
-HANDLE, DWORD, and NULL are temporarily defined within pthread.h if
-they are not already.
-
-
-pthread.h, sched.h and semaphore.h now use dllexport/dllimport
---------------------------------------------------------------
-Not only to avoid the need for the pthread.def file, but to
-improve performance. Apparently, declaring functions with dllimport
-generates a direct call to the function and avoids the overhead
-of a stub function call.
-
-Bug fixes
----------
-* Fixed potential NULL pointer dereferences in pthread_mutexattr_init,
-pthread_mutexattr_getpshared, pthread_barrierattr_init,
-pthread_barrierattr_getpshared, and pthread_condattr_getpshared.
-- Scott McCaskill <scott@magruder.org>
-
-* Removed potential race condition in pthread_mutex_trylock and
-pthread_mutex_lock;
-- Alexander Terekhov <TEREKHOV@de.ibm.com>
-
-* The behaviour of pthread_mutex_trylock in relation to
-recursive mutexes was inconsistent with commercial implementations.
-Trylock would return EBUSY if the lock was owned already by the
-calling thread regardless of mutex type. Trylock now increments the
-recursion count and returns 0 for RECURSIVE mutexes, and will
-return EDEADLK rather than EBUSY for ERRORCHECK mutexes. This is
-consistent with Solaris.
-- Thomas Pfaff <tpfaff@gmx.net>
-
-* Found a fix for the library and workaround for applications for
-the known bug #2, i.e. where __CLEANUP_CXX or __CLEANUP_SEH is defined.
-See the "Known Bugs in this snapshot" section below.
-
-This could be made transparent to applications by replacing the macros that
-define the current C++ and SEH versions of pthread_cleanup_push/pop
-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
-return an error (ESRCH).
-
-* errno: An incorrect compiler directive caused a local version
-of errno to be used instead of the Win32 errno. Both instances are
-thread-safe but applications checking errno after a pthreads-win32
-call would be wrong. Fixing this also fixed a bad compiler
-option in the testsuite (/MT should have been /MD) which is
-needed to link with the correct library MSVCRT.LIB.
-
-
-SNAPSHOT 2001-07-12
--------------------
-
-To be added
-
-
-SNAPSHOT 2001-07-03
--------------------
-
-To be added
-
-
-SNAPSHOT 2000-08-13
--------------------
-
-New:
--       Renamed DLL and LIB files:
-                pthreadVSE.dll  (MS VC++/Structured EH)
-                pthreadVSE.lib
-                pthreadVCE.dll  (MS VC++/C++ EH)
-                pthreadVCE.lib
-                pthreadGCE.dll  (GNU G++/C++ EH)
-                libpthreadw32.a
-
-        Both your application and the pthread dll should use the
-        same exception handling scheme.
-
-Bugs fixed:
--       MSVC++ C++ exception handling.
-
-Some new tests have been added.
-
-
-SNAPSHOT 2000-08-10
--------------------
-
-New:
--       asynchronous cancelation on X86 (Jason Nye)
--       Makefile compatible with MS nmake to replace
-        buildlib.bat
--       GNUmakefile for Mingw32
--       tests/Makefile for MS nmake replaces runall.bat
--       tests/GNUmakefile for Mingw32
-
-Bugs fixed:
--       kernel32 load/free problem
--       attempt to hide internel exceptions from application
-        exception handlers (__try/__except and try/catch blocks)
--       Win32 thread handle leakage bug
-        (David Baggett/Paul Redondo/Eyal Lebedinsky)
-
-Some new tests have been added.
-
-
-SNAPSHOT 1999-11-02
--------------------
-
-Bugs fixed:
--       ctime_r macro had an incorrect argument (Erik Hensema),
--       threads were not being created 
-        PTHREAD_CANCEL_DEFERRED. This should have
-        had little effect as deferred is the only
-        supported type. (Ross Johnson).
-
-Some compatibility improvements added, eg.
--       pthread_setcancelstate accepts NULL pointer
-        for the previous value argument. Ditto for
-        pthread_setcanceltype. This is compatible
-        with Solaris but should not affect
-        standard applications (Erik Hensema)
-
-Some new tests have been added.
-
-
-SNAPSHOT 1999-10-17
--------------------
-
-Bug fix - Cancelation of threads waiting on condition variables
-now works properly (Lorin Hochstein and Peter Slacik)
-
-
-SNAPSHOT 1999-08-12
--------------------
-
-Fixed exception stack cleanup if calling pthread_exit()
-- (Lorin Hochstein and John Bossom).
-
-Fixed bugs in condition variables - (Peter Slacik):
-        - additional contention checks
-        - properly adjust number of waiting threads after timed
-          condvar timeout.
-
-
-SNAPSHOT 1999-05-30
--------------------
-
-Some minor bugs have been fixed. See the ChangeLog file for details.
-
-Some more POSIX 1b functions are now included but ony return an
-error (ENOSYS) if called. They are:
-
-        sem_open
-        sem_close
-        sem_unlink
-        sem_getvalue
-
-
-SNAPSHOT 1999-04-07
--------------------
-
-Some POSIX 1b functions which were internally supported are now
-available as exported functions:
-
-        sem_init
-        sem_destroy
-        sem_wait
-        sem_trywait
-        sem_post
-        sched_yield
-        sched_get_priority_min
-        sched_get_priority_max
-
-Some minor bugs have been fixed. See the ChangeLog file for details.
-
-
-SNAPSHOT 1999-03-16
--------------------
-
-Initial release.
-
+CURRENT CVS HEAD Version

+RELEASE 2.9.0 pending

+-------------

+(2010-??-??)

+

+General

+-------

+New bug fixes in this release since 2.8.0 have NOT been applied to the

+1.x.x series.

+

+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.

+

+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.

+

+New Features

+------------

+Dependence on the winsock library is now discretionary via

+#define RETAIN_WSALASTERROR in config.h. It is undefined by default unless

+WINCE is defined (because I (RJ) am unsure of the dependency there).

+- Ramiro Polla

+

+(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 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.

+See README.NONPORTABLE for descriptions of these routines.

+- Ramiro Polla

+

+Bug fixes

+---------

+Various modifications and fixes to build and test for WinCE.

+- Marcel Ruff, Sinan Kaya

+

+Fix pthread_cond_destroy() - should not be a cancellation point. Other

+minor build problems fixed.

+- Romano Paolo Tenca

+

+Remove potential deadlock condition from pthread_cond_destroy().

+- Eric Berge

+

+Various modifications to build and test for Win64.

+- Kip Streithorst

+

+Various fixes to the QueueUserAPCEx async cancellation helper DLL

+(this is a separate download) and pthreads code cleanups.

+- Sebastian Gottschalk

+

+Removed potential NULL pointer reference.

+- Robert Kindred

+

+Removed the requirement that applications restrict the number of threads

+calling pthread_barrier_wait() [on the same barrier] to just the barrier

+count in order to avoid contention and dead lock. Also reduced the

+contention between barrier_wait and barrier_destroy. This change will

+have slowed barriers down slightly but halves the number of semaphores

+consumed per barrier to one.

+- Ross Johnson

+

+RELEASE 2.8.0

+-------------

+(2006-12-22)

+

+General

+-------

+New bug fixes in this release since 2.7.0 have not been applied to the

+version 1.x.x series. It is probably time to drop version 1.

+

+Testing and verification

+------------------------

+This release has not yet been tested on SMP architechtures. All tests pass

+on a uni-processor system.

+

+Bug fixes

+---------

+Sem_destroy could return EBUSY even though no threads were waiting on the 

+semaphore. Other races around invalidating semaphore structs (internally)

+have been removed as well.

+

+New tests

+---------

+semaphore5.c - tests the bug fix referred to above.

+

+

+RELEASE 2.7.0

+-------------

+(2005-06-04)

+

+General

+-------

+All new features in this release have been back-ported in release 1.11.0,

+including the incorporation of MCS locks in pthread_once, however, versions

+1 and 2 remain incompatible even though they are now identical in

+performance and functionality.

+

+Testing and verification

+------------------------

+This release has been tested (passed the test suite) on both uni-processor

+and multi-processor systems.

+- Tim Theisen

+

+Bug fixes

+---------

+Pthread_once has been re-implemented to remove priority boosting and other

+complexity to improve robustness. Races for Win32 handles that are not

+recycle-unique have been removed. The general form of pthread_once is now

+the same as that suggested earlier by Alexander Terekhov, but instead of the

+'named mutex', a queue-based lock has been implemented which has the required

+properties of dynamic self initialisation and destruction. This lock is also

+efficient. The ABI is unaffected in as much as the size of pthread_once_t has

+not changed and PTHREAD_ONCE_INIT has not changed, however, applications that

+peek inside pthread_once_t, which is supposed to be opaque, will break.

+- Vladimir Kliatchko

+

+New features

+------------

+* Support for Mingw cross development tools added to GNUmakefile.

+Mingw cross tools allow building the libraries on Linux.

+- Mikael Magnusson

+

+

+RELEASE 2.6.0

+-------------

+(2005-05-19)

+

+General

+-------

+All of the bug fixes and new features in this release have been

+back-ported in release 1.10.0.

+

+Testing and verification

+------------------------

+This release has been tested (passed the test suite) on both uni-processor

+and multi-processor systems. Thanks to Tim Theisen at TomoTherapy for

+exhaustively running the MP tests and for providing crutial observations

+and data when faults are detected.

+

+Bugs fixed

+----------

+

+* pthread_detach() now reclaims remaining thread resources if called after

+the target thread has terminated. Previously, this routine did nothing in

+this case.

+

+New tests

+---------

+

+* detach1.c - tests that pthread_detach properly invalidates the target

+thread, which indicates that the thread resources have been reclaimed.

+

+

+RELEASE 2.5.0

+-------------

+(2005-05-09)

+

+General

+-------

+

+The package now includes a reference documentation set consisting of

+HTML formatted Unix-style manual pages that have been edited for

+consistency with Pthreads-w32. The set can also be read online at:

+http://sources.redhat.com/pthreads-win32/manual/index.html

+

+Thanks again to Tim Theisen for running the test suite pre-release

+on an MP system.

+

+All of the bug fixes and new features in this release have been

+back-ported in release 1.9.0.

+

+Bugs fixed

+----------

+

+* Thread Specific Data (TSD) key management has been ammended to

+eliminate a source of (what was effectively) resource leakage (a HANDLE

+plus memory for each key destruct routine/thread association). This was

+not a true leak because these resources were eventually reclaimed when

+pthread_key_delete was run AND each thread referencing the key had exited.

+The problem was that these two conditions are often not met until very

+late, and often not until the process is about to exit.

+

+The ammended implementation avoids the need for the problematic HANDLE

+and reclaims the memory as soon as either the key is deleted OR the

+thread exits, whichever is first.

+

+Thanks to Richard Hughes at Aculab for identifying and locating the leak.

+

+* TSD key destructors are now processed up to PTHREAD_DESTRUCTOR_ITERATIONS

+times instead of just once. PTHREAD_DESTRUCTOR_ITERATIONS has been

+defined in pthread.h for some time but not used.

+

+* Fix a semaphore accounting race between sem_post/sem_post_multiple

+and sem_wait cancellation. This is the same issue as with

+sem_timedwait that was fixed in the last release.

+

+* sem_init, sem_post, and sem_post_multiple now check that the

+semaphore count never exceeds _POSIX_SEM_VALUE_MAX.

+

+* Although sigwait() is nothing more than a no-op, it should at least

+be a cancellation point to be consistent with the standard.

+

+New tests

+---------

+

+* stress1.c - attempts to expose problems in condition variable

+and semaphore timed wait logic. This test was inspired by Stephan

+Mueller's sample test code used to identify the sem_timedwait bug

+from the last release. It's not a part of the regular test suite

+because it can take awhile to run. To run it:

+nmake clean VC-stress

+

+* tsd2.c - tests that key destructors are re-run if the tsd key value is

+not NULL after the destructor routine has run. Also tests that

+pthread_setspecific() and pthread_getspecific() are callable from

+destructors.

+

+

+RELEASE 2.4.0

+-------------

+(2005-04-26)

+

+General

+-------

+

+There is now no plan to release a version 3.0.0 to fix problems in

+pthread_once(). Other possible implementations of pthread_once

+will still be investigated for a possible future release in an attempt

+to reduce the current implementation's complexity.

+

+All of the bug fixes and new features in this release have been

+back-ported for release 1.8.0.

+

+Bugs fixed

+----------

+

+* Fixed pthread_once race (failures on an MP system). Thanks to

+Tim Theisen for running exhaustive pre-release testing on his MP system

+using a range of compilers:

+  VC++ 6

+  VC++ 7.1

+  Intel C++ version 8.0

+All tests passed.

+Some minor speed improvements were also done.

+

+* Fix integer overrun error in pthread_mutex_timedlock() - missed when

+sem_timedwait() was fixed in release 2.2.0. This routine no longer returns

+ENOTSUP when NEED_SEM is defined - it is supported (NEED_SEM is only

+required for WinCE versions prior to 3.0).

+

+* Fix timeout bug in sem_timedwait().

+- Thanks to Stephan Mueller for reporting, providing diagnostic output

+and test code.

+

+* Fix several problems in the NEED_SEM conditionally included code.

+NEED_SEM included code is provided for systems that don't implement W32

+semaphores, such as WinCE prior to version 3.0. An alternate implementation

+of POSIX semaphores is built using W32 events for these systems when

+NEED_SEM is defined. This code has been completely rewritten in this

+release to reuse most of the default POSIX semaphore code, and particularly,

+to implement all of the sem_* routines supported by pthreads-win32. Tim

+Theisen also run the test suite over the NEED_SEM code on his MP system. All

+tests passed.

+

+* The library now builds without errors for the Borland Builder 5.5 compiler.

+

+New features

+------------

+

+* pthread_mutex_timedlock() and all sem_* routines provided by

+pthreads-win32 are now implemented for WinCE versions prior to 3.0. Those

+versions did not implement W32 semaphores. Define NEED_SEM in config.h when

+building the library for these systems.

+

+Known issues in this release

+----------------------------

+

+* pthread_once is too complicated - but it works as far as testing can

+determine..

+

+* The Borland version of the dll fails some of the tests with a memory read

+exception. The cause is not yet known but a compiler bug has not been ruled

+out.

+

+

+RELEASE 2.3.0

+-------------

+(2005-04-12)

+

+General

+-------

+

+Release 1.7.0 is a backport of features and bug fixes new in

+this release. See earlier notes under Release 2.0.0/General.

+

+Bugs fixed

+----------

+

+* Fixed pthread_once potential for post once_routine cancellation

+hanging due to starvation. See comments in pthread_once.c.

+Momentary priority boosting is used to ensure that, after a

+once_routine is cancelled, the thread that will run the

+once_routine is not starved by higher priority waiting threads at

+critical times. Priority boosting occurs only AFTER a once_routine 

+cancellation, and is applied only to that once_control. The

+once_routine is run at the thread's normal base priority.

+

+New tests

+---------

+

+* once4.c: Aggressively tests pthread_once() under realtime

+conditions using threads with varying priorities. Windows'

+random priority boosting does not occur for threads with realtime

+priority levels.

+

+

+RELEASE 2.2.0

+-------------

+(2005-04-04)

+

+General

+-------

+

+* Added makefile targets to build static link versions of the library.

+Both MinGW and MSVC. Please note that this does not imply any change

+to the LGPL licensing, which still imposes psecific conditions on

+distributing software that has been statically linked with this library.

+

+* There is a known bug in pthread_once(). Cancellation of the init_routine

+exposes a potential starvation (i.e. deadlock) problem if a waiting thread

+has a higher priority than the initting thread. This problem will be fixed

+in version 3.0.0 of the library.

+

+Bugs fixed

+----------

+

+* Fix integer overrun error in sem_timedwait().

+Kevin Lussier

+

+* Fix preprocessor directives for static linking.

+Dimitar Panayotov

+

+

+RELEASE 2.1.0

+-------------

+(2005-03-16)

+

+Bugs fixed

+----------

+

+* Reverse change to pthread_setcancelstate() in 2.0.0.

+

+

+RELEASE 2.0.0

+-------------

+(2005-03-16)

+

+General

+-------

+

+This release represents an ABI change and the DLL version naming has

+incremented from 1 to 2, e.g. pthreadVC2.dll.

+

+Version 1.4.0 back-ports the new functionality included in this

+release. Please distribute DLLs built from that version with updates

+to applications built on pthreads-win32 version 1.x.x.

+

+The package naming has changed, replacing the snapshot date with 

+the version number + descriptive information. E.g. this

+release is "pthreads-w32-2-0-0-release".

+

+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.

+

+New features

+------------

+

+* pthread_once() now supports init_routine cancellability.

+

+New tests

+---------

+

+* Agressively test pthread_once() init_routine cancellability.

+

+

+SNAPSHOT 2005-03-08

+-------------------

+Version 1.3.0

+

+Bug reports (fixed)

+-------------------

+

+* Implicitly created threads leave Win32 handles behind after exiting.

+- Dmitrii Semii

+

+* pthread_once() starvation problem.

+- Gottlob Frege

+

+New tests

+---------

+

+* More intense testing of pthread_once().

+

+

+SNAPSHOT 2005-01-25

+-------------------

+Version 1.2.0

+

+Bug fixes

+---------

+

+* Attempted acquisition of a recursive mutex could cause waiting threads

+to not be woken when the mutex was released.

+- Ralf Kubis  <RKubis at mc.com>

+

+* Various package omissions have been fixed.

+

+

+SNAPSHOT 2005-01-03

+-------------------

+Version 1.1.0

+

+Bug fixes

+---------

+

+* Unlocking recursive or errorcheck mutexes would sometimes

+unexpectedly return an EPERM error (bug introduced in

+snapshot-2004-11-03).

+- Konstantin Voronkov  <beowinkle at yahoo.com>

+

+

+SNAPSHOT 2004-11-22

+-------------------

+Version 1.0.0

+

+This snapshot primarily fixes the condvar bug introduced in

+snapshot-2004-11-03. DLL versioning has also been included to allow

+applications to runtime check the Microsoft compatible DLL version

+information, and to extend the DLL naming system for ABI and major

+(non-backward compatible) API changes. See the README file for details.

+

+Bug fixes

+---------

+

+* Condition variables no longer deadlock (bug introduced in

+snapshot-2004-11-03).

+- Alexander Kotliarov and Nicolas at saintmac

+

+* DLL naming extended to avoid 'DLL hell' in the future, and to

+accommodate the ABI change introduced in snapshot-2004-11-03. Snapshot

+2004-11-03 will be removed from FTP sites.

+

+New features

+------------

+

+* A Microsoft-style version resource has been added to the DLL for

+applications that wish to check DLL compatibility at runtime.

+

+* Pthreads-win32 DLL naming has been extended to allow incompatible DLL

+versions to co-exist in the same filesystem. See the README file for details,

+but briefly: while the version information inside the DLL will change with

+each release from now on, the DLL version names will only change if the new

+DLL is not backward compatible with older applications.

+

+The versioning scheme has been borrowed from GNU Libtool, and the DLL

+naming scheme is from Cygwin. Provided the Libtool-style numbering rules are

+honoured, the Cygwin DLL naming scheme automatcally ensures that DLL name

+changes are minimal and that applications will not load an incompatible

+pthreads-win32 DLL.

+

+Those who use the pre-built DLLs will find that the DLL/LIB names have a new

+suffix (1) in this snapshot. E.g. pthreadVC1.dll etc.

+

+* The POSIX thread ID reuse uniqueness feature introduced in the last snapshot

+has been kept as default, but the behaviour can now be controlled when the DLL

+is built to effectively switch it off. This makes the library much more

+sensitive to applications that assume that POSIX thread IDs are unique, i.e.

+are not strictly compliant with POSIX. See the PTW32_THREAD_ID_REUSE_INCREMENT

+macro comments in config.h for details.

+

+Other changes

+-------------

+Certain POSIX macros have changed.

+

+These changes are intended to conform to the Single Unix Specification version 3,

+which states that, if set to 0 (zero) or not defined, then applications may use

+sysconf() to determine their values at runtime. Pthreads-win32 does not

+implement sysconf().

+

+The following macros are no longer undefined, but defined and set to -1

+(not implemented):

+

+      _POSIX_THREAD_ATTR_STACKADDR

+      _POSIX_THREAD_PRIO_INHERIT

+      _POSIX_THREAD_PRIO_PROTECT

+      _POSIX_THREAD_PROCESS_SHARED

+

+The following macros are defined and set to 200112L (implemented):

+

+      _POSIX_THREADS

+      _POSIX_THREAD_SAFE_FUNCTIONS

+      _POSIX_THREAD_ATTR_STACKSIZE

+      _POSIX_THREAD_PRIORITY_SCHEDULING

+      _POSIX_SEMAPHORES

+      _POSIX_READER_WRITER_LOCKS

+      _POSIX_SPIN_LOCKS

+      _POSIX_BARRIERS

+

+The following macros are defined and set to appropriate values:

+

+      _POSIX_THREAD_THREADS_MAX

+      _POSIX_SEM_VALUE_MAX

+      _POSIX_SEM_NSEMS_MAX

+      PTHREAD_DESTRUCTOR_ITERATIONS

+      PTHREAD_KEYS_MAX

+      PTHREAD_STACK_MIN

+      PTHREAD_THREADS_MAX

+

+

+SNAPSHOT 2004-11-03

+-------------------

+

+DLLs produced from this snapshot cannot be used with older applications without

+recompiling the application, due to a change to pthread_t to provide unique POSIX

+thread IDs.

+

+Although this snapshot passes the extended test suite, many of the changes are

+fairly major, and some applications may show different behaviour than previously,

+so adopt with care. Hopefully, any changed behaviour will be due to the library

+being better at it's job, not worse.

+

+Bug fixes

+---------

+

+* pthread_create() no longer accepts NULL as the thread reference arg.

+A segfault (memory access fault) will result, and no thread will be

+created.

+

+* pthread_barrier_wait() no longer acts as a cancelation point.

+

+* Fix potential race condition in pthread_once()

+- Tristan Savatier  <tristan at mpegtv.com>

+

+* Changes to pthread_cond_destroy() exposed some coding weaknesses in several

+test suite mini-apps because pthread_cond_destroy() now returns EBUSY if the CV

+is still in use.

+

+New features

+------------

+

+* Added for compatibility:

+PTHREAD_RECURSIVE_MUTEX_INITIALIZER,

+PTHREAD_ERRORCHECK_MUTEX_INITIALIZER,

+PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP,

+PTHREAD_ERRORCHECK_MUTEX_INITIALIZER_NP

+

+* Initial support for Digital Mars compiler

+- Anuj Goyal  <anuj.goyal at gmail.com>

+

+* Faster Mutexes. These have been been rewritten following a model provided by

+Alexander Terekhov that reduces kernel space checks, and eliminates some additional

+critical sections used to manage a race between timedlock expiration and unlock.

+Please be aware that the new mutexes do not enforce strict absolute FIFO scheduling

+of mutexes, however any out-of-order lock acquisition should be very rare.

+

+* Faster semaphores. Following a similar model to mutexes above, these have been

+rewritten to use preliminary users space checks.

+

+* sem_getvalue() now returns the number of waiters.

+

+* The POSIX thread ID now has much stronger uniqueness characteristics. The library

+garrantees not to reuse the same thread ID for at least 2^(wordsize) thread

+destruction/creation cycles.

+

+New tests

+---------

+

+* semaphore4.c: Tests cancelation of the new sem_wait().

+

+* semaphore4t.c: Likewise for sem_timedwait().

+

+* rwlock8.c: Tests and times the slow execution paths of r/w locks, and the CVs,

+mutexes, and semaphores that they're built on.

+

+

+SNAPSHOT 2004-05-16

+-------------------

+

+Attempt to add Watcom to the list of compilers that can build the library.

+This failed in the end due to it's non-thread-aware errno. The library

+builds but the test suite fails. See README.Watcom for more details.

+

+Bug fixes

+---------

+* Bug and memory leak in sem_init()

+- Alex Blanco  <Alex.Blanco at motorola.com>

+

+* ptw32_getprocessors() now returns CPU count of 1 for WinCE.

+- James Ewing  <james.ewing at sveasoft.com>

+

+* pthread_cond_wait() could be canceled at a point where it should not

+be cancelable. Fixed.

+- Alexander Terekhov  <TEREKHOV at de.ibm.com>

+

+* sem_timedwait() had an incorrect timeout calculation.

+- Philippe Di Cristo  <philipped at voicebox.com>

+

+* Fix a memory leak left behind after threads are destroyed.

+- P. van Bruggen  <pietvb at newbridges.nl>

+

+New features

+------------

+* Ported to AMD64.

+- Makoto Kato  <raven at oldskool.jp>

+

+* True pre-emptive asynchronous cancelation 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

+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.

+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

+feature is a welcome addition with respect to the library's conformance to

+the POSIX standard.

+

+SNAPSHOT 2003-09-18

+-------------------

+

+Cleanup of thread priority management. In particular, setting of thread

+priority now attempts to map invalid Win32 values within the range returned

+by sched_get_priority_min/max() to useful values. See README.NONPORTABLE

+under "Thread priority".

+

+Bug fixes

+---------

+* pthread_getschedparam() now returns the priority given by the most recent

+call to pthread_setschedparam() or established by pthread_create(), as

+required by the standard. Previously, pthread_getschedparam() incorrectly

+returned the running thread priority at the time of the call, which may have

+been adjusted or temporarily promoted/demoted.

+

+* sched_get_priority_min() and sched_get_priority_max() now return -1 on error

+and set errno. Previously, they incorrectly returned the error value directly.

+

+

+SNAPSHOT 2003-09-04

+-------------------

+

+Bug fixes

+---------

+* ptw32_cancelableWait() now allows cancelation of waiting implicit POSIX

+threads.

+

+New test

+--------

+* cancel8.c tests cancelation of Win32 threads waiting at a POSIX cancelation

+point.

+

+

+SNAPSHOT 2003-09-03

+-------------------

+

+Bug fixes

+---------

+* pthread_self() would free the newly created implicit POSIX thread handle if

+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

+---------------------------------------------------------

+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

+deferred). Now it does.

+

+Any thread can be canceled by any other thread (Win32 or POSIX) if the former

+thread's POSIX pthread_t value is known. It's TSD destructors and POSIX

+cleanup handlers will be run before the thread exits with an exit code of

+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).

+

+By adding cancelation, 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.

+

+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

+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

+necessary and return the pthread_t value.

+

+New tests

+---------

+Test the above new feature.

+

+

+SNAPSHOT 2003-08-19

+-------------------

+

+This snapshot fixes some accidental corruption to new test case sources.

+There are no changes to the library source code.

+

+

+SNAPSHOT 2003-08-15

+-------------------

+

+Bug fixes

+---------

+

+* pthread.dsp now uses correct compile flags (/MD).

+- Viv  <vcotirlea@hotmail.com>

+

+* pthread_win32_process_detach_np() fixed memory leak.

+- Steven Reddie  <Steven.Reddie@ca.com>

+

+* pthread_mutex_destroy() fixed incorrect return code.

+- Nicolas Barry  <boozai@yahoo.com>

+

+* pthread_spin_destroy() fixed memory leak.

+- Piet van Bruggen  <pietvb@newbridges.nl>

+

+* Various changes to tighten arg checking, and to work with later versions of

+MinGW32 and MsysDTK.

+

+* pthread_getschedparam() etc, fixed dangerous thread validity checking.

+- Nicolas Barry  <boozai@yahoo.com>

+

+* POSIX thread handles are now reused and their memory is not freed on thread exit.

+This allows for stronger thread validity checking.

+

+New standard routine

+--------------------

+

+* pthread_kill() added to provide thread validity checking to applications.

+It does not accept any non zero values for the signal arg.

+

+New test cases

+--------------

+

+* New test cases to confirm validity checking, pthread_kill(), and thread reuse.

+

+

+SNAPSHOT 2003-05-10

+-------------------

+

+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.

+- Thomas Pfaff  <tpfaff@gmx.net>

+

+* pthread_mutex_timedlock() no longer occasionally sets incorrect mutex

+ownership, causing deadlocks in some applications.

+- Robert Strycek <strycek@posam.sk> and Alexander Terekhov  <TEREKHOV@de.ibm.com>

+

+

+SNAPSHOT 2002-11-04

+-------------------

+

+Bug fixes

+---------

+

+* sem_getvalue() now returns the correct value under Win NT and WinCE.

+- Rob Fanner  <rfanner@stonethree.com>

+

+* sem_timedwait() now uses tighter checks for unreasonable

+abstime values - that would result in unexpected timeout values.

+

+* ptw32_cond_wait_cleanup() no longer mysteriously consumes

+CV signals but may produce more spurious wakeups. It is believed

+that the sem_timedwait() call is consuming a CV signal that it

+shouldn't.

+- Alexander Terekhov  <TEREKHOV@de.ibm.com>

+

+* Fixed a memory leak in ptw32_threadDestroy() for implicit threads.

+

+* Fixed potential for deadlock in pthread_cond_destroy().

+A deadlock could occur for statically declared CVs (PTHREAD_COND_INITIALIZER),

+when one thread is attempting to destroy the condition variable while another

+is attempting to dynamically initialize it.

+- Michael Johnson  <michaelj@maine.rr.com>

+

+

+SNAPSHOT 2002-03-02

+-------------------

+

+Cleanup code default style. (IMPORTANT)

+----------------------------------------------------------------------

+Previously, if not defined, the cleanup style was determined automatically

+from the compiler/language, and one of the following was defined accordingly:

+

+        __CLEANUP_SEH   MSVC only

+        __CLEANUP_CXX   C++, including MSVC++, GNU G++

+        __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

+pthread_exit) is performed (see the routine ptw32_throw() in private.c).

+

+In short, the exceptions versions of the library throw an exception

+when a thread is canceled or exits (via pthread_exit()), which is

+caught by a handler in the thread startup routine, so that the

+the correct stack unwinding occurs regardless of where the thread

+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,

+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

+may be an exception (no pun intended) and possible future trend.

+

+Although it was not clearly documented before, it is still necessary to

+build your application using the same __CLEANUP_* define as was

+used for the version of the library that you link with, so that the

+correct parts of pthread.h are included. That is, the possible

+defines require the following library versions:

+

+        __CLEANUP_SEH   pthreadVSE.dll

+        __CLEANUP_CXX   pthreadVCE.dll or pthreadGCE.dll

+        __CLEANUP_C     pthreadVC.dll or pthreadGC.dll

+

+E.g. regardless of whether your app is C or C++, if you link with

+pthreadVC.lib or libpthreadGC.a, then you must define __CLEANUP_C.

+

+

+THE POINT OF ALL THIS IS: if you have not been defining one of these

+explicitly, then the defaults as described at the top of this

+section were being used.

+

+THIS NOW CHANGES, as has been explained above, but to try to make this

+clearer here's an example:

+

+If you were building your application with MSVC++ i.e. using C++

+exceptions and not explicitly defining one of __CLEANUP_*, then

+__CLEANUP_C++ was automatically defined for you in pthread.h.

+You should have been linking with pthreadVCE.dll, which does

+stack unwinding.

+

+If you now build your application as you had before, pthread.h will now

+automatically set __CLEANUP_C as the default style, and you will need to

+link with pthreadVC.dll. Stack unwinding will now NOT occur when a thread

+is canceled, or the thread calls pthread_exit().

+

+Your application will now most likely behave differently to previous

+versions, and in non-obvious ways. Most likely is that locally

+instantiated objects may not be destroyed or cleaned up after a thread

+is canceled.

+

+If you want the same behaviour as before, then you must now define

+__CLEANUP_C++ explicitly using a compiler option and link with

+pthreadVCE.dll as you did before.

+

+

+WHY ARE WE MAKING THE DEFAULT STYLE LESS EXCEPTION-FRIENDLY?

+Because no commercial Unix POSIX threads implementation allows you to

+choose to have stack unwinding. Therefore, providing it in pthread-win32

+as a default is dangerous. We still provide the choice but unless

+you consciously choose to do otherwise, your pthreads applications will

+now run or crash in similar ways irrespective of the threads platform

+you use. Or at least this is the hope.

+

+

+WHY NOT REMOVE THE EXCEPTIONS VERSIONS OF THE LIBRARY ALTOGETHER?

+There are a few reasons:

+- because there are well respected POSIX threads people who believe

+  that POSIX threads implementations should be exceptions aware and

+  do the expected thing in that context. (There are equally respected

+  people who believe it should not be easily accessible, if it's there

+  at all, for unconditional conformity to other implementations.)

+- because pthreads-win32 is one of the few implementations that has

+  the choice, perhaps the only freely available one, and so offers

+  a laboratory to people who may want to explore the effects;

+- although the code will always be around somewhere for anyone who

+  wants it, once it's removed from the current version it will not be

+  nearly as visible to people who may have a use for it.

+

+

+Source module splitting

+-----------------------

+In order to enable smaller image sizes to be generated

+for applications that link statically with the library,

+most routines have been separated out into individual

+source code files.

+

+This is being done in such a way as to be backward compatible.

+The old source files are reused to congregate the individual

+routine files into larger translation units (via a bunch of

+# includes) so that the compiler can still optimise wherever

+possible, e.g. through inlining, which can only be done

+within the same translation unit.

+

+It is also possible to build the entire library by compiling

+the single file named "pthread.c", which just #includes all

+the secondary congregation source files. The compiler

+may be able to use this to do more inlining of routines.

+

+Although the GNU compiler is able to produce libraries with

+the necessary separation (the -ffunction-segments switch),

+AFAIK, the MSVC and other compilers don't have this feature.

+

+Finally, since I use makefiles and command-line compilation,

+I don't know what havoc this reorganisation may wreak amongst

+IDE project file users. You should be able to continue

+using your existing project files without modification.

+

+

+New non-portable functions

+--------------------------

+pthread_num_processors_np():

+  Returns the number of processors in the system that are

+  available to the process, as determined from the processor

+  affinity mask.

+

+pthread_timechange_handler_np():

+  To improve tolerance against operator or time service initiated

+  system clock changes.

+

+  This routine can be called by an application when it

+  receives a WM_TIMECHANGE message from the system. At present

+  it broadcasts all condition variables so that waiting threads

+  can wake up and re-evaluate their conditions and restart

+  their timed waits if required.

+  - Suggested by Alexander Terekhov

+

+

+Platform dependence

+-------------------

+As Win95 doesn't provide one, the library now contains

+it's own InterlockedCompareExchange() routine, which is used

+whenever Windows doesn't provide it. InterlockedCompareExchange()

+is used to implement spinlocks and barriers, and also in mutexes.

+This routine relies on the CMPXCHG machine instruction which

+is not available on i386 CPUs. This library (from snapshot

+20010712 onwards) is therefore no longer supported on i386

+processor platforms.

+

+

+New standard routines

+---------------------

+For source code portability only - rwlocks cannot be process shared yet.

+

+        pthread_rwlockattr_init()

+        pthread_rwlockattr_destroy()

+        pthread_rwlockattr_setpshared()

+        pthread_rwlockattr_getpshared()

+

+As defined in the new POSIX standard, and the Single Unix Spec version 3:

+

+        sem_timedwait()

+        pthread_mutex_timedlock()    - Alexander Terekhov and Thomas Pfaff

+        pthread_rwlock_timedrdlock() - adapted from pthread_rwlock_rdlock()

+        pthread_rwlock_timedwrlock() - adapted from pthread_rwlock_wrlock()

+

+

+pthread.h no longer includes windows.h

+--------------------------------------

+[Not yet for G++]

+

+This was done to prevent conflicts.

+

+HANDLE, DWORD, and NULL are temporarily defined within pthread.h if

+they are not already.

+

+

+pthread.h, sched.h and semaphore.h now use dllexport/dllimport

+--------------------------------------------------------------

+Not only to avoid the need for the pthread.def file, but to

+improve performance. Apparently, declaring functions with dllimport

+generates a direct call to the function and avoids the overhead

+of a stub function call.

+

+Bug fixes

+---------

+* Fixed potential NULL pointer dereferences in pthread_mutexattr_init,

+pthread_mutexattr_getpshared, pthread_barrierattr_init,

+pthread_barrierattr_getpshared, and pthread_condattr_getpshared.

+- Scott McCaskill <scott@magruder.org>

+

+* Removed potential race condition in pthread_mutex_trylock and

+pthread_mutex_lock;

+- Alexander Terekhov <TEREKHOV@de.ibm.com>

+

+* The behaviour of pthread_mutex_trylock in relation to

+recursive mutexes was inconsistent with commercial implementations.

+Trylock would return EBUSY if the lock was owned already by the

+calling thread regardless of mutex type. Trylock now increments the

+recursion count and returns 0 for RECURSIVE mutexes, and will

+return EDEADLK rather than EBUSY for ERRORCHECK mutexes. This is

+consistent with Solaris.

+- Thomas Pfaff <tpfaff@gmx.net>

+

+* Found a fix for the library and workaround for applications for

+the known bug #2, i.e. where __CLEANUP_CXX or __CLEANUP_SEH is defined.

+See the "Known Bugs in this snapshot" section below.

+

+This could be made transparent to applications by replacing the macros that

+define the current C++ and SEH versions of pthread_cleanup_push/pop

+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

+return an error (ESRCH).

+

+* errno: An incorrect compiler directive caused a local version

+of errno to be used instead of the Win32 errno. Both instances are

+thread-safe but applications checking errno after a pthreads-win32

+call would be wrong. Fixing this also fixed a bad compiler

+option in the testsuite (/MT should have been /MD) which is

+needed to link with the correct library MSVCRT.LIB.

+

+

+SNAPSHOT 2001-07-12

+-------------------

+

+To be added

+

+

+SNAPSHOT 2001-07-03

+-------------------

+

+To be added

+

+

+SNAPSHOT 2000-08-13

+-------------------

+

+New:

+-       Renamed DLL and LIB files:

+                pthreadVSE.dll  (MS VC++/Structured EH)

+                pthreadVSE.lib

+                pthreadVCE.dll  (MS VC++/C++ EH)

+                pthreadVCE.lib

+                pthreadGCE.dll  (GNU G++/C++ EH)

+                libpthreadw32.a

+

+        Both your application and the pthread dll should use the

+        same exception handling scheme.

+

+Bugs fixed:

+-       MSVC++ C++ exception handling.

+

+Some new tests have been added.

+

+

+SNAPSHOT 2000-08-10

+-------------------

+

+New:

+-       asynchronous cancelation on X86 (Jason Nye)

+-       Makefile compatible with MS nmake to replace

+        buildlib.bat

+-       GNUmakefile for Mingw32

+-       tests/Makefile for MS nmake replaces runall.bat

+-       tests/GNUmakefile for Mingw32

+

+Bugs fixed:

+-       kernel32 load/free problem

+-       attempt to hide internel exceptions from application

+        exception handlers (__try/__except and try/catch blocks)

+-       Win32 thread handle leakage bug

+        (David Baggett/Paul Redondo/Eyal Lebedinsky)

+

+Some new tests have been added.

+

+

+SNAPSHOT 1999-11-02

+-------------------

+

+Bugs fixed:

+-       ctime_r macro had an incorrect argument (Erik Hensema),

+-       threads were not being created 

+        PTHREAD_CANCEL_DEFERRED. This should have

+        had little effect as deferred is the only

+        supported type. (Ross Johnson).

+

+Some compatibility improvements added, eg.

+-       pthread_setcancelstate accepts NULL pointer

+        for the previous value argument. Ditto for

+        pthread_setcanceltype. This is compatible

+        with Solaris but should not affect

+        standard applications (Erik Hensema)

+

+Some new tests have been added.

+

+

+SNAPSHOT 1999-10-17

+-------------------

+

+Bug fix - Cancelation of threads waiting on condition variables

+now works properly (Lorin Hochstein and Peter Slacik)

+

+

+SNAPSHOT 1999-08-12

+-------------------

+

+Fixed exception stack cleanup if calling pthread_exit()

+- (Lorin Hochstein and John Bossom).

+

+Fixed bugs in condition variables - (Peter Slacik):

+        - additional contention checks

+        - properly adjust number of waiting threads after timed

+          condvar timeout.

+

+

+SNAPSHOT 1999-05-30

+-------------------

+

+Some minor bugs have been fixed. See the ChangeLog file for details.

+

+Some more POSIX 1b functions are now included but ony return an

+error (ENOSYS) if called. They are:

+

+        sem_open

+        sem_close

+        sem_unlink

+        sem_getvalue

+

+

+SNAPSHOT 1999-04-07

+-------------------

+

+Some POSIX 1b functions which were internally supported are now

+available as exported functions:

+

+        sem_init

+        sem_destroy

+        sem_wait

+        sem_trywait

+        sem_post

+        sched_yield

+        sched_get_priority_min

+        sched_get_priority_max

+

+Some minor bugs have been fixed. See the ChangeLog file for details.

+

+

+SNAPSHOT 1999-03-16

+-------------------

+

+Initial release.

+