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