PTHREADS-WIN32 ============== Pthreads-win32 is free software, distributed under the GNU Lesser General Public License (LGPL). See the file 'COPYING.LIB' for terms and conditions. Also see the file 'COPYING' for information specific to pthreads-win32, copyrights and the LGPL. What is it? ----------- Pthreads-win32 is an Open Source Software implementation of the Threads component of the POSIX 1003.1c 1995 Standard (or later) 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, plus some common and pthreads-win32 specific non-portable routines (see README.NONPORTABLE). See the file "ANNOUNCE" for more information including standards conformance details and the list of supported and unsupported routines. Prerequisites ------------- MSVC or GNU C (MSys - MinGW32) To build from source. QueueUserAPCEx by Panagiotis E. Hadjidoukas For true async cancelation of threads (including blocked threads). This is a DLL and Windows driver that provides pre-emptive APC by forcing threads into an alertable state when the APC is queued. Both the DLL and driver are provided with the pthreads-win32.exe self-unpacking ZIP, and on the pthreads-win32 FTP site (in source and pre-built forms). Currently this is a separate LGPL package to pthreads-win32. See the README in the QueueUserAPCEx folder for installation instructions. Pthreads-win32 will automatically detect if the QueueUserAPCEx DLL QuserEx.DLL is available and whether the driver AlertDrv.sys is loaded. If it is not available, pthreads-win32 will simulate async cancelation, which means that it cannot pre-empt blocked threads. Library naming -------------- 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 Which of the several dll versions to use? ----------------------------------------- or, --- What are all these pthread*.dll and pthread*.lib files? ------------------------------------------------------- Simple, use either pthreadGC.* if you use GCC, or pthreadVC.* if you use MSVC. Otherwise, you need to choose carefully and know WHY. 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. The default version uses setjmp/longjmp. There is some contension amongst POSIX threads experts as to how POSIX threads cancelation and exit should work with languages that use exceptions, 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 for the reason that 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 differently when linked with other pthreads libraries. Now you may be asking: then 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 it would be difficult to find. - 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. Notes: [If you use either pthreadVCE or pthreadGCE] 1. [See also the discussion in the FAQ file - Q2, Q4, and Q5] If your application contains catch(...) blocks in your POSIX threads then you will need to replace the "catch(...)" with the macro "PtW32Catch", eg. #ifdef PtW32Catch PtW32Catch { ... } #else catch(...) { ... } #endif Otherwise neither pthreads cancelation nor pthread_exit() will work reliably when using versions of the library that use C++ exceptions for cancelation and thread exit. This is due to what is believed to be a C++ compliance error in VC++ whereby you may not have multiple handlers for the same exception in the same try/catch block. GNU G++ doesn't have this restriction. Other name changes ------------------ All snapshots prior to and including snapshot 2000-08-13 used "_pthread_" as the prefix to library internal functions, and "_PTHREAD_" to many library internal macros. These have now been changed to "ptw32_" and "PTW32_" respectively so as to not conflict with the ANSI standard's reservation of identifiers beginning with "_" and "__" for use by compiler implementations only. If you have written any applications and you are linking statically with the pthreads-win32 library then you may have included a call to _pthread_processInitialize. You will now have to change that to ptw32_processInitialize. Cleanup code default style -------------------------- Previously, 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(). In this snapshot, 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/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 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 (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, 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. Building under VC++ using C++ EH, Structured EH, or just C ---------------------------------------------------------- From the source directory run one of the following: nmake clean VC (builds the VC setjmp/longjmp version of pthreadVC.dll) or: nmake clean VCE (builds the VC++ C++ EH version pthreadVCE.dll) or: nmake clean VSE (builds the VC++ structured EH version pthreadVSE.dll) You can run the testsuite by changing to the "tests" directory and running the target corresponding to the DLL version you built: nmake clean VC or: nmake clean VCE or: nmake clean VSE or: nmake clean VCX (tests the VC version of the library with C++ (EH) applications) Building under Mingw32 ---------------------- The dll can be built easily with recent versions of Mingw32. (The distributed versions are built using Mingw32 and MsysDTK from www.mingw32.org.) From the source directory, run make clean GC or: make clean GCE You can run the testsuite by changing to the "tests" directory and running make clean GC or: make clean GCE or: make clean GCX (tests the GC version of the library with C++ (EH) applications) Building the library under Cygwin --------------------------------- Not tested by me although I think some people have done this. Not sure how successfully though. Cygwin is implementing it's own POSIX threads routines and these will be the ones to use if you develop using Cygwin. Ready to run binaries --------------------- For convenience, the following ready-to-run files can be downloaded from the FTP site (see under "Availability" below): pthread.h semaphore.h sched.h pthread.def pthreadVC.dll - built with MSVC compiler using C setjmp/longjmp pthreadVC.lib pthreadVCE.dll - built with MSVC++ compiler using C++ EH pthreadVCE.lib pthreadVSE.dll - built with MSVC compiler using SEH pthreadVSE.lib pthreadGC.dll - built with Mingw32 GCC libpthreadGC.a - derived from pthreadGC.dll pthreadGCE.dll - built with Mingw32 G++ libpthreadGCE.a - derived from pthreadGCE.dll As of August 2003 pthreads-win32 pthreadG* versions are built and tested using the MinGW + MsysDTK environment current as of that date or later. The following file MAY be needed for older MinGW environments. gcc.dll - needed to build and run applications that use pthreadGCE.dll. Building applications with GNU compilers ---------------------------------------- If you're using pthreadGC.dll: With the three header files, pthreadGC.dll and libpthreadGC.a in the same directory as your application myapp.c, you could compile, link and run myapp.c under Mingw32 as follows: gcc -o myapp.exe myapp.c -I. -L. -lpthreadGC myapp Or put pthreadGC.dll in an appropriate directory in your PATH, put libpthreadGC.a in your system lib directory, and put the three header files in your system include directory, then use: gcc -o myapp.exe myapp.c -lpthreadGC myapp If you're using pthreadGCE.dll: With the three header files, pthreadGCE.dll, gcc.dll and libpthreadGCE.a in the same directory as your application myapp.c, you could compile, link and run myapp.c under Mingw32 as follows: gcc -x c++ -o myapp.exe myapp.c -I. -L. -lpthreadGCE myapp Or put pthreadGCE.dll and gcc.dll in an appropriate directory in your PATH, put libpthreadGCE.a in your system lib directory, and put the three header files in your system include directory, then use: gcc -x c++ -o myapp.exe myapp.c -lpthreadGCE myapp Availability ------------ The complete source code in either unbundled, self-extracting Zip file, or tar/gzipped format can be found at: ftp://sources.redhat.com/pub/pthreads-win32 The pre-built DLL, export libraries and matching pthread.h can be found at: ftp://sources.redhat.com/pub/pthreads-win32/dll-latest Home page: http://sources.redhat.com/pthreads-win32/ Mailing list ------------ There is a mailing list for discussing pthreads on Win32. To join, send email to: pthreads-win32-subscribe@sources.redhat.com Unsubscribe by sending mail to: pthreads-win32-unsubscribe@sources.redhat.com Acknowledgements ---------------- Pthreads-win32 is based substantially on a Win32 Pthreads implementation contributed by John E. Bossom. Many others have contributed important new code, improvements and bug fixes. Thanks go to Alexander Terekhov and Louis Thomas for their implementation of condition variables (see README.CV). Thanks also to the authors of the following paper, which served as the first CV design, and which identifies the important issues: "Strategies for Implementing POSIX Condition Variables on Win32" - http://www.cs.wustl.edu/~schmidt/win32-cv-1.html See the 'CONTRIBUTORS' file for the list of contributors. As much as possible, the ChangeLog file attributes contributions and patches that have been incorporated in the library to the individuals responsible. Finally, thanks to all those who work on and contribute to the POSIX and Single Unix Specification standards. The maturity of an industry can be measured by it's open standards. ---- Ross Johnson