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