From 0fee04f5eb2d9c1c484281afbc2b24278567a179 Mon Sep 17 00:00:00 2001 From: rpj Date: Tue, 8 Jan 2002 07:22:44 +0000 Subject: Update docs. --- ANNOUNCE | 23 ++++++++++++----------- README | 43 +++++++++++++++++++++++++++++++++++++++++-- 2 files changed, 53 insertions(+), 13 deletions(-) diff --git a/ANNOUNCE b/ANNOUNCE index 6b9f0e5..d3b7a00 100644 --- a/ANNOUNCE +++ b/ANNOUNCE @@ -16,7 +16,7 @@ Parts of the implementation also comply with the Open Group's Single Unix specification for compatibility with major Unix implementations and Linux. -Pthreads-win32 is free software, distributed under the GNU Library +Pthreads-win32 is free software, distributed under the GNU Lesser General Public License (LGPL). Please see the 'Acknowledgements' section at the end of this @@ -29,13 +29,14 @@ Changes since the last snapshot platform dependence ------------------- -As Win9x doesn't provide one, the library now contains -it's own InterlockedCompareExchange() routine. It is used to -implement spinlocks and barriers, and also in mutexes. +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 only available in i486 or above CPUs. This library -(from snapshot 20010712 onwards) therefore no longer runs on -i386 platforms. +is not available on i386 CPUs. This library (from snapshot +20010712 onwards) is therefore no longer supported on i386 +processor platforms. rwlocks ------- @@ -55,10 +56,10 @@ pthread_mutex_lock; 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 -regardless of mutex type. Trylock now increments the recursion -count and returns 0 for RECURSIVE mutexes, and will now return -EDEADLCK instead of EBUSY for ERRORCHECK mutexes. This is +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 diff --git a/README b/README index cce698f..cc24f6e 100644 --- a/README +++ b/README @@ -1,9 +1,10 @@ PTHREADS-WIN32 ============== -Pthreads-win32 is free software, distributed under the GNU Library +Pthreads-win32 is free software, distributed under the GNU Lesser General Public License (LGPL). See the file 'COPYING.LIB' for terms -and conditions. +and conditions. Also see the file 'COPYING' for information +specific to pthreads-win32, copyrights and the LGPL. What is it? @@ -21,6 +22,44 @@ See the file "ANNOUNCE" for more information including standards conformance details and list of supported routines. +Which of the several dll versions to use? +----------------------------------------- +or, What are all these pthread*.dll files? +------------------------------------------ + +Simply, you only use one of them, but you need to choose carefully. + +The most important choice you need to make is whether to use a +version that uses exceptions internally, or not (there are versions +of the library that use exceptions as part of the thread +cancelation and exit implementation, and one that uses +setjmp/longjmp instead). + +There is some contension amongst POSIX threads experts as +to how POSIX threads cancelation and exit should work +with languages that include exceptions and handlers, e.g. +C++ and even C (Microsoft's Structured Exceptions). + +The issue is: should cancelation of a thread in a, say, +C++ application cause object destructors and C++ exception +handlers to be invoked as the stack unwinds during thread +exit, or not? + +Your choice will depend primarily on whether your application +is intended to be cross-platform or not, and how the POSIX threads +implementations on the target platforms handle this issue. That is, +you'll want consistent behaviour. + +If you can't choose now, it's probably best to use the +standard C version of the library, even if your application +is being written in C++. You will need to handle the +potentially adverse effects of thread cancelation in your +code, but at least you will have the best chance of +consistency of behaviour across platforms. If you later +decide to use an exception handling version of the library +then you will hopefully have fewer, if any, changes to make. + + Library naming -------------- -- cgit v1.2.3