diff options
Diffstat (limited to 'NEWS')
| -rw-r--r-- | NEWS | 1772 |
1 files changed, 886 insertions, 886 deletions
@@ -1,886 +1,886 @@ -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.
-
+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. + |