diff options
| author | rpj <rpj> | 2002-01-31 06:56:03 +0000 |
|---|---|---|
| committer | rpj <rpj> | 2002-01-31 06:56:03 +0000 |
| commit | 75f8ad67d45d48b9cdde5a298083881790c76c73 (patch) | |
| tree | 0d793e00b40a3292f1fee2b302eb6eccdf15d113 /FAQ | |
| parent | 30a1e9738593302fa26e0a668f517bc7f5800190 (diff) | |
2002-01-27 Ross Johnson <rpj@special.ise.canberra.edu.au>
* mutex.c (pthread_mutex_timedlock): New function suggested by
Alexander Terekhov. The logic required to implement this
properly came from Alexander, with some collaboration
with Thomas Pfaff.
(pthread_mutex_unlock): Wrap the waiters check and sema
post in a critical section to prevent a race with
pthread_mutex_timedlock.
(ptw32_timed_semwait): New function;
returns a special result if the absolute timeout parameter
represents a time already passed when called; used by
pthread_mutex_timedwait(). Have deliberately not reused
the name "ptw32_sem_timedwait" because they are not the same
routine.
* condvar.c (ptw32_cond_timedwait): Use the new sem_timedwait()
instead of ptw32_sem_timedwait(), which now has a different
function. See previous.
* implement.h: Remove prototype for ptw32_sem_timedwait.
See next.
(pthread_mutex_t_): Add critical section element for access
to lock_idx during mutex post-timeout processing.
* semaphore.h (sem_timedwait): See next.
* semaphore.c (sem_timedwait): See next.
* private.c (ptw32_sem_timedwait): Move to semaphore.c
and rename as sem_timedwait().
2002-01-18 Ross Johnson <rpj@special.ise.canberra.edu.au>
* sync.c (pthread_join): Was getting the exit code from the
calling thread rather than the joined thread if
defined(__MINGW32__) && !defined(__MSVCRT__).
2002-01-15 Ross Johnson <rpj@special.ise.canberra.edu.au>
* pthread.h: Unless the build explicitly defines __CLEANUP_SEH,
__CLEANUP_CXX, or __CLEANUP_C, then the build defaults to
__CLEANUP_C style cleanup. This style uses setjmp/longjmp
in the cancelation and thread exit implementations and therefore
won't do stack unwinding if linked to applications that have it
(e.g. C++ apps). This is currently consistent with most/all
commercial Unix POSIX threads implementations.
* spin.c (pthread_spin_init): Edit renamed function call.
* nonportable.c (pthread_num_processors_np): New.
(pthread_getprocessors_np): Renamed to ptw32_getprocessors
and moved to private.c.
* private.c (pthread_getprocessors): Moved here from
nonportable.c.
* pthread.def (pthread_getprocessors_np): Removed
from export list.
* rwlock.c (pthread_rwlockattr_init): New.
(pthread_rwlockattr_destroy): New.
(pthread_rwlockattr_getpshared): New.
(pthread_rwlockattr_setpshared): New.
Diffstat (limited to 'FAQ')
| -rw-r--r-- | FAQ | 257 |
1 files changed, 228 insertions, 29 deletions
@@ -5,27 +5,236 @@ INDEX
-----
-Q 1 Should I use Cygwin or Mingw32 as a development environment?
+Q 1 What is it?
-Q 2 Now that pthreads-win32 builds under Mingw32, why do I get
- memory access violations?
+Q 2 Which of the several dll versions do I use?
+ or,
+ What are all these pthread*.dll and pthread*.lib files?
-Q 3 How do I use pthread.dll for Win32 (Visual C++ 5.0)
+Q 3 What is the library naming convention?
-Q 4 Cancelation doesn't work for me, why?
+Q 4 Cleanup code default style or: it used to work when I built
+ the library myself, but now it doesn't - why?
-Q 5 Thread won't block after two calls to mutex_lock
+Q 5 Why is the default library version now less exception-friendly?
-Q 6 How do I generate pthreadGCE.dll and libpthreadw32.a for use with Mingw32?
+Q 6 Should I use Cygwin or Mingw32 as a development environment?
+
+Q 7 Now that pthreads-win32 builds under Mingw32, why do I get
+ memory access violations (segfaults)?
+
+Q 8 How do I use pthread.dll for Win32 (Visual C++ 5.0)
+
+Q 9 Cancelation doesn't work for me, why?
+
+Q 10 Thread won't block after two calls to mutex_lock
+
+Q 11 How do I generate pthreadGCE.dll and libpthreadw32.a for use with Mingw32?
=============================================================================
-Q 1 Should I use Cygwin or Mingw32 as a development environment?
+Q 1 What is it?
---
-A 1
+Pthreads-win32 is an Open Source Software implementation of the
+Threads component of the POSIX 1003.1c 1995 Standard for Microsoft's
+Win32 environment. Some functions from POSIX 1003.1b are also
+supported including semaphores. Other related functions include
+the set of read-write lock functions. The library also supports
+some of the functionality of the Open Group's Single Unix
+specification, version 2, namely mutex types.
+
+See the file "ANNOUNCE" for more information including standards
+conformance details and list of supported routines.
+
+
+Q 2 Which of the several dll versions do I use?
+--- or,
+ What are all these pthread*.dll and pthread*.lib 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, say,
+a C++ application cause object destructors and C++ exception
+handlers to be invoked as the stack unwinds during thread
+exit, or not?
+
+There seems to be more opinion in favour of using the
+standard C version of the library (no EH) with C++ applications
+since this appears to be the assumption commercial pthreads
+implementations make. Therefore, if you use an EH version
+of pthreads-win32 then you may be under the illusion that
+your application will be portable, when in fact it is likely to
+behave very differently linked with other pthreads libraries.
+
+Now you may be asking: why have you kept the EH versions of
+the library?
+
+There are a couple of reasons:
+- there is division amongst the experts and so the code may
+ be needed in the future. (Yes, it's in the repository and we
+ can get it out anytime in the future, but ...)
+- pthreads-win32 is one of the few implementations, and possibly
+ the only freely available one, that has EH versions. It may be
+ useful to people who want to play with or study application
+ behaviour under these conditions.
+
+
+Q 3 What is the library naming convention?
---
-Important: see Q2 also.
+
+Because the library is being built using various exception
+handling schemes and compilers - and because the library
+may not work reliably if these are mixed in an application,
+each different version of the library has it's own name.
+
+Note 1: the incompatibility is really between EH implementations
+of the different compilers. It should be possible to use the
+standard C version from either compiler with C++ applications
+built with a different compiler. If you use an EH version of
+the library, then you must use the same compiler for the
+application. This is another complication and dependency that
+can be avoided by using only the standard C library version.
+
+Note 2: if you use a standard C pthread*.dll with a C++
+application, then any functions that you define that are
+intended to be called via pthread_cleanup_push() must be
+__cdecl.
+
+Note 3: the intention is to also name either the VC or GC
+version (it should be arbitrary) as pthread.dll, including
+pthread.lib and libpthread.a as appropriate.
+
+In general:
+ pthread[VG]{SE,CE,C}.dll
+ pthread[VG]{SE,CE,C}.lib
+
+where:
+ [VG] indicates the compiler
+ V - MS VC
+ G - GNU C
+
+ {SE,CE,C} indicates the exception handling scheme
+ SE - Structured EH
+ CE - C++ EH
+ C - no exceptions - uses setjmp/longjmp
+
+For example:
+ pthreadVSE.dll (MSVC/SEH)
+ pthreadGCE.dll (GNUC/C++ EH)
+ pthreadGC.dll (GNUC/not dependent on exceptions)
+
+The GNU library archive file names have changed to:
+
+ libpthreadGCE.a
+ libpthreadGC.a
+
+
+Q 4 Cleanup code default style or: it used to work when I built
+--- the library myself, but now it doesn't - why?
+
+Up to and including snapshot 2001-07-12, if not defined, the cleanup
+style was determined automatically from the compiler used, 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().
+
+After snapshot 2001-07-12, unless your 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/all
+commercial Unix POSIX threads implementations.
+
+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
+
+THE POINT OF ALL THIS IS: if you have not been defining one of these
+explicitly, then the defaults have been set according to the compiler
+and language you are using, as described at the top of this
+section.
+
+THIS NOW CHANGES, as has been explained above. For example:
+
+If you were building your application with MSVC++ i.e. using C++
+exceptions (rather than SEH) and not explicitly defining one of
+__CLEANUP_*, then __CLEANUP_C++ was 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
+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, nor when 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 local
+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.
+
+
+Q 5 Why is the default library version now 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
+you must now consciously make it.
+
+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.)
+- 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.
+
+
+Q 6 Should I use Cygwin or Mingw32 as a development environment?
+---
+
+Important: see Q7 also.
In short, use Mingw32 with the MSVCRT library to build applications that use
the DLL. Cygwin's own internal support for POSIX threads is growing. Consult
@@ -83,11 +292,9 @@ Anders ------------------------------------------------------------------------------
-Q 2 Now that pthreads-win32 builds under Mingw32, why do I get
+Q 7 Now that pthreads-win32 builds under Mingw32, why do I get
--- memory access violations (segfaults)?
-A 2
----
Note: issue resolved.
The latest Mingw32 package has thread-safe exception handling.
Make sure you also read A 6 below to get a fully working build.
@@ -143,11 +350,9 @@ Kevin ------------------------------------------------------------------------------
-Q 3 How do I use pthread.dll for Win32 (Visual C++ 5.0)
+Q 8 How do I use pthread.dll for Win32 (Visual C++ 5.0)
---
-A 3
----
>
> I'm a "rookie" when it comes to your pthread implementation. I'm currently
> desperately trying to install the prebuilt .dll file into my MSVC compiler.
@@ -182,11 +387,9 @@ Ross ------------------------------------------------------------------------------
-Q 4 Cancelation doesn't work for me, why?
+Q 9 Cancelation doesn't work for me, why?
---
-A 4
----
> I'm investigating a problem regarding thread cancelation. The thread I want
> to cancel has PTHREAD_CANCEL_ASYNCHRONOUS, however, this piece of code
> blocks on the join():
@@ -264,11 +467,9 @@ Ross ------------------------------------------------------------------------------
-Q 5 Thread won't block after two calls to mutex_lock
----
-
-A 5
----
+Q 10 Thread won't block after two calls to mutex_lock
+----
+
> i was testing this pthread for win32 in my prog.
> when i checked if it was blocking mutex_lock calls, i was surprised when it
> didnt lock
@@ -303,11 +504,9 @@ Ross ------------------------------------------------------------------------------
-Q 6 How do I generate pthreadGCE.dll and libpthreadw32.a for use with Mingw32?
----
-
-A 6
----
+Q 11 How do I generate pthreadGCE.dll and libpthreadw32.a for use with Mingw32?
+----
+
Once you've followed Thomas Pfaff's instructions below to fix
Mingw32, then you can simply run "make" to build the library and dll.
|