''

1 files changed, 893 insertions, 893 deletions

diff --git a/NEWS b/NEWS
index 61560ff..39950a9 100644
--- a/NEWS
+++ b/NEWS
@@ -1,893 +1,893 @@
-RELEASE 1.7.0

--------------

-(2005-04-12)

-

-General

--------

-

-This release is a backport of features and bug fixes new in

-release 2.3.0. See earlier notes under Release 1.4.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 1.6.0

--------------

-(2005-04-04)

-

-General

--------

-

-This release is a backport of features and bug fixes new in

-release 2.2.0. See earlier notes under Release 1.4.0/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 specific conditions on

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

-

-Bugs fixed

-----------

-

-* Fix integer overrun error in sem_timedwait().

-Kevin Lussier

-

-* Fix preprocessor directives for static linking.

-Dimitar Panayotov

-

-

-RELEASE 1.5.0

--------------

-(2005-03-16)

-

-General

--------

-

-This release is a backport of features and bug fixes new in

-release 2.1.0. See earlier notes under Release 1.4.0/General.

-

-Bugs fixed

-----------

-

-* Reverse change to pthread_setcancelstate() made in 1.4.0.

-

-

-RELEASE 1.4.0

--------------

-(2005-03-16)

-

-General

--------

-

-Version 2.0.0 is being released and version 1.4.0 back-ports the

-functionality included in that release. In future, bug fixes

-will be back-ported if possible and where appropriate, however,

-this will be at the maintainer's descretion. New features will

-not generally be back-ported, although some may if they

-provide major improvements in compatibility with the standard.

-

-This is intended as a courtesy to application developers, but as

-time moves on, the imperative will fade.

-

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

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

-release is "pthreads-w32-1-4-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.

-

+RELEASE 1.7.0
+-------------
+(2005-04-12)
+
+General
+-------
+
+This release is a backport of features and bug fixes new in
+release 2.3.0. See earlier notes under Release 1.4.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 1.6.0
+-------------
+(2005-04-04)
+
+General
+-------
+
+This release is a backport of features and bug fixes new in
+release 2.2.0. See earlier notes under Release 1.4.0/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 specific conditions on
+distributing software that has been statically linked with this library.
+
+Bugs fixed
+----------
+
+* Fix integer overrun error in sem_timedwait().
+Kevin Lussier
+
+* Fix preprocessor directives for static linking.
+Dimitar Panayotov
+
+
+RELEASE 1.5.0
+-------------
+(2005-03-16)
+
+General
+-------
+
+This release is a backport of features and bug fixes new in
+release 2.1.0. See earlier notes under Release 1.4.0/General.
+
+Bugs fixed
+----------
+
+* Reverse change to pthread_setcancelstate() made in 1.4.0.
+
+
+RELEASE 1.4.0
+-------------
+(2005-03-16)
+
+General
+-------
+
+Version 2.0.0 is being released and version 1.4.0 back-ports the
+functionality included in that release. In future, bug fixes
+will be back-ported if possible and where appropriate, however,
+this will be at the maintainer's descretion. New features will
+not generally be back-ported, although some may if they
+provide major improvements in compatibility with the standard.
+
+This is intended as a courtesy to application developers, but as
+time moves on, the imperative will fade.
+
+The package naming has changed, replacing the snapshot date with
+the version number + descriptive information. E.g. this
+release is "pthreads-w32-1-4-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.
+