Update docs.

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 <tpfaff@gmx.net>

 

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

 --------------