From 8d1d0ccda9d99994348609d51c03488ae3bddf90 Mon Sep 17 00:00:00 2001 From: rpj Date: Mon, 17 May 2004 04:05:46 +0000 Subject: '' --- NEWS | 1054 +++++++++++++++++++++++++++++---------------------------- README.Watcom | 62 ++++ 2 files changed, 595 insertions(+), 521 deletions(-) create mode 100644 README.Watcom diff --git a/NEWS b/NEWS index 83d983f..695ff5d 100644 --- a/NEWS +++ b/NEWS @@ -28,21 +28,33 @@ New features * Ported to AMD64. - Makoto Kato -* True pre-emptive asynchronous cancelation of threads. 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. +* 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 +------------------- -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 +Bug fixes --------- * pthread_getschedparam() now returns the priority given by the most recent call to pthread_setschedparam() or established by pthread_create(), as @@ -54,516 +66,516 @@ been adjusted or temporarily promoted/demoted. 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 - -* pthread_win32_process_detach_np() fixed memory leak. -- Steven Reddie - -* pthread_mutex_destroy() fixed incorrect return code. -- Nicolas Barry - -* pthread_spin_destroy() fixed memory leak. -- Piet van Bruggen - -* 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 - -* 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 - -* pthread_mutex_timedlock() no longer occasionally sets incorrect mutex -ownership, causing deadlocks in some applications. -- Robert Strycek and Alexander Terekhov - - -SNAPSHOT 2002-11-04 -------------------- - -Bug fixes ---------- - -* sem_getvalue() now returns the correct value under Win NT and WinCE. -- Rob Fanner - -* 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 - -* 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 - - -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 - -* Removed potential race condition in pthread_mutex_trylock and -pthread_mutex_lock; -- Alexander Terekhov - -* 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 - -* 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. - +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 + +* pthread_win32_process_detach_np() fixed memory leak. +- Steven Reddie + +* pthread_mutex_destroy() fixed incorrect return code. +- Nicolas Barry + +* pthread_spin_destroy() fixed memory leak. +- Piet van Bruggen + +* 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 + +* 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 + +* pthread_mutex_timedlock() no longer occasionally sets incorrect mutex +ownership, causing deadlocks in some applications. +- Robert Strycek and Alexander Terekhov + + +SNAPSHOT 2002-11-04 +------------------- + +Bug fixes +--------- + +* sem_getvalue() now returns the correct value under Win NT and WinCE. +- Rob Fanner + +* 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 + +* 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 + + +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 + +* Removed potential race condition in pthread_mutex_trylock and +pthread_mutex_lock; +- Alexander Terekhov + +* 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 + +* 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. + diff --git a/README.Watcom b/README.Watcom new file mode 100644 index 0000000..2974928 --- /dev/null +++ b/README.Watcom @@ -0,0 +1,62 @@ +Watcom compiler notes +===================== + +Status +------ +Not yet usable. Although the library builds under Watcom it +substantially fails the test suite. + +There is a working Wmakefile for wmake for the library build. + +invoke as any of: +wmake -f Wmakefile clean WC +wmake -f Wmakefile clean WC-inlined +wmake -f Wmakefile clean WCE +wmake -f Wmakefile clean WCE-inlined + +These build pthreadWC.dll and pthreadWCE.dll. + +There is a working Wmakefile for wmake for the test suite. + +invoke as any of: +wmake -f Wmakefile clean WC +wmake -f Wmakefile clean WCX +wmake -f Wmakefile clean WCE +wmake -f Wmakefile clean WC-bench +wmake -f Wmakefile clean WCX-bench +wmake -f Wmakefile clean WCE-bench + + +Current known problems +---------------------- + +Library build: +The Watcom compiler uses a different default call convention to MS C or GNU C and so +applications are not compatible with pthreadVC.dll etc using pre 2003-10-14 versions +of pthread.h, sched.h, or semaphore.h. The cdecl attribute can be used on exposed +function prototypes to force compatibility with MS C built DLLs. + +However, there appear to be other incompatibilities. Errno.h, for example, defines +different values for the standard C and POSIX errors to those defined by the MS C +errno.h. It may be that references to Watcom's threads compatible 'errno' do set +and return translated numbers consistently, but I have not verified this. + +Watcom defines errno as a dereferenced pointer returned by the function +_get_errno_ptr(). This is similar to both the MS and GNU C environments for +multithreaded use. However, the Watcom version appears to have a number of problems: + +- different threads return the same pointer value. Compare with the MS and GNU C +versions which correctly return different values (since each thread must maintain +a thread specific errno value). + +- an errno value set within the DLL appears as zero in the application even though +both share the same thread. + +Therefore applications built using the Watcom compiler may need to use +a Watcom built version of the library (pthreadWC.dll). If this is the case, then +the cdecl function attribute should not be required. + +Application builds: +The test suite fails with the Watcom compiler. + +Test semaphore1.c fails for pthreadWC.dll because errno returns 0 instead of EAGAIN. -- cgit v1.2.3