diff options
| -rw-r--r-- | ANNOUNCE | 23 | ||||
| -rw-r--r-- | README | 43 |
2 files changed, 53 insertions, 13 deletions
@@ -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>
@@ -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
--------------
|