From 9e771b529dfb74600baf3c0234e247d5fa166524 Mon Sep 17 00:00:00 2001 From: rpj Date: Fri, 29 Dec 2000 07:14:46 +0000 Subject: Updated. --- ANNOUNCE | 129 +++++++++++++++++++++++++++++++++++++++++++-------------------- README | 50 ++++++++++++++++++------- 2 files changed, 125 insertions(+), 54 deletions(-) diff --git a/ANNOUNCE b/ANNOUNCE index 22ed166..09ee33d 100644 --- a/ANNOUNCE +++ b/ANNOUNCE @@ -1,5 +1,5 @@ - PTHREADS-WIN32 SNAPSHOT 2000-09-08 + PTHREADS-WIN32 SNAPSHOT 2000-12-29 ---------------------------------- Web Site: http://sources.redhat.com/pthreads-win32/ FTP Site: ftp://sources.redhat.com/pub/pthreads-win32 @@ -26,16 +26,37 @@ Change Summary (since the last snapshot) (See the ChangeLog file for details.) New: -- New non-portable function (see the README file): - pthread_getw32threadhandle_np +- New non-portable functions for use when statically linking the library + (see the README file): + pthread_delay_np + pthread_win32_process_attach_np + pthread_win32_process_detach_np + pthread_win32_thread_attach_np + pthread_win32_thread_detach_np + Also, the start of support within the library for statically + linked applications, but this has not been tested by statically + linking yet. +- A fully working MinGW32 g++ compiled version of the library + is now supplied. To use with g++ compiled applications + please see the FAQ "How do I generate pthreadGCE.dll and + libpthreadw32.a for use with Mingw32", which you need to do + before compiling and linking applications as well. +- Unhandled exceptions, whether SEH or C++, are no longer + silently caught and ignored but are passed out of threads for + the system to deal with. C++ applications can override + the default termination handler via set_terminate(). + set_terminate() works fine for MinGW32 g++ but not yet with MS VC++ + (see known bugs (2)) even though it's the same code. See + tests/exception3.c for an example of using set_terminate(). Bugs fixed: -- Calling pthread_cancel from non-POSIX threads fixed. -- Possible deadlock threat using pthread_cond_broadcast() reduced. -- TSD key creation race condition; -- Other potential race conditions - associated with initialising various - pthreads objects. +- Pthread_mutex_unlock() now returns EPERM if the unlocking + thread does not currently hold the thread. +- Args in the ctime_r macro in pthread.h are fixed. +- Made semaphore.h independent of config.h when building + applications. Don't know how this went unnoticed for so long + - the default defines must have been correct for my test + environment. Some new tests have been added. @@ -45,17 +66,17 @@ Known bugs in this snapshot 1. Asynchronous cancelation only works on Intel X86 machines. -2. Running the test "join1.c" with the library built with Mingw32 -and the GNUmakefile included, the test fails with a segmentation (invalid -page access) exception. The fault appears to be in the assembler code -emmitted by the compiler [to handle exception contexts] at the -end of the try block in ptw32_threadStart(). - -3. There are problems using the libpthreadw32.a stub archive derived -from either of pthreadVSE.dll or pthreadVCE.dll. The cleanup1.c test -fails. This is now an expected result of having different EH and cleanup -handler schemes in the library and application. +2. Under MS VC++ (only tested with version 6.0), a term_func + set via the standard C++ set_terminate() function is not called + for some reason. The code - in private.c:ptw32_threadStart() - + makes an explicit call to terminate() which works as expected + under MinGW32 g++ doesn't appear to run the term_func under + MC VC++ 6.0. +3. This is an interim snapshot as there are still some additional + patches to go in, eg. to fix problems with errno support under + some circumstances. Some people are seeing compile warnings + to do with _errno. Caveats ------- @@ -212,6 +233,11 @@ The following functions are implemented: --------------------------- pthread_mutexattr_setforcecs_np pthread_getw32threadhandle_np + pthread_delay_np + pthread_win32_process_attach_np + pthread_win32_process_detach_np + pthread_win32_thread_attach_np + pthread_win32_thread_detach_np --------------------------- Static Initializers (macros) @@ -326,14 +352,13 @@ Application Development Environments MSVC: MSVC using SEH works. -MSVC using C++ EH not tested. +MSVC using C++ EH works. + +Mingw32: +You need gcc-2.95.2-1 modified as per pthreads-win32 FAQ answer (6), with +binutils-19990818-1 and msvcrt runtime-2000-03-27. Mingw32 must use +the thread-safe MSVCRT library (see the FAQ). -Mingw32: (ftp://ftp.xraylith.wisc.edu/pub/khan/gnu-win32/mingw32/egcs-1.1.1/) -Mingw32 must use the thread-safe MSVCRT library (see the FAQ). You can link -against the export library libpthread32.a built under Mingw32 -but you must run your application with the version of pthread.dll built -with MSVC. See the "Known bugs" section above. - Cygwin: (http://sourceware.cygnus.com/cygwin/) Cygwin aims to provide a complete POSIX environment on top of Win32, including threads. When this is complete, developers using Cygwin will not need @@ -341,17 +366,24 @@ pthreads-win32. At this time, Cygwin has preliminary support for multithreaded development, however, this is not turned on by default. We have not tested pthreads-win32 against Cygwin. +UWIN: +UWIN is a complete Unix-like environment for Windows from AT&T. Pthreads-win32 +doesn't currently support UWIN (and vice versa), but that may change in the +future. + Generally: For convenience, the following pre-built files are available on the FTP site (see Availability above): - pthread.h - for POSIX 1c threads - semaphore.h - for POSIX 1b semaphores - sched.h - for POSIX 1b scheduling - pthread.dll - built with MSVC cl compiler on NT4.0 - pthread.lib - built with MSVC cl compiler on NT4.0 - libpthread32.a - built with Mingw32 on Win98 (use with - MSVC pthread.dll for runtime) + pthread.h - for POSIX 1c threads + semaphore.h - for POSIX 1b semaphores + sched.h - for POSIX 1b scheduling + pthreadVCE.dll - built with MSVC++ compiler using C++ EH + pthreadVCE.lib + pthreadVSE.dll - built with MSVC compiler using SEH + pthreadVSE.lib + pthreadGCE.dll - built with Mingw32 G++ + libpthreadw32.a - derived from pthreadGCE.dll These are the only files you need in order to build POSIX threads applications for Win32 using either MSVC or Mingw32. @@ -359,15 +391,32 @@ applications for Win32 using either MSVC or Mingw32. See the FAQ file in the source tree for additional information. -Building the library with MSVC ------------------------------- +Building the library with MSVC from source +------------------------------------------ + +A simple makefile for building the library with MSVC is available. Just +run nmake in a command shell in the pthreads source directory for targets +to make either the VSE or VCE version of the library. Eg: + + cd \pthreads + nmake clean VSE +or + nmake clean VCE + +There are currently no nmake targets to make statically linked +versions of the library. + +Building the library with MinGW32 from source +--------------------------------------------- + +Run make in the pthreads source directory. Ie: -A simple makefile for building the library with MSVC is available. The -Makefile by default links the library to MSVCRT.DLL. If your application -uses another C runtime library like LIBCMT.LIB, please edit the Makefile to -avoid conflicts between C-libraries. + cd \pthreads + make clean + make -There is also a batch file "buildlib.bat" which will build the library. +The GNU make utility will find the GNUmakefile in the pthreads source +directory. Documentation diff --git a/README b/README index 93bf8cd..0ca6271 100644 --- a/README +++ b/README @@ -160,6 +160,39 @@ pthread_delay_np (const struct timespec *interval); 0 Successful completion. [EINVAL] The value specified by interval is invalid. + +BOOL +pthread_win32_process_attach_np (void); + +BOOL +pthread_win32_process_detach_np (void); + +BOOL +pthread_win32_thread_attach_np (void); + +BOOL +pthread_win32_thread_detach_np (void); + + These functions contain the code normally run via dllMain + when the library is used as a dll but which need to be + called explicitly by an application when the library + is statically linked. + + You will need to call pthread_win32_process_attach_np() before + you can call any pthread routines when statically linking. + You should call pthread_win32_process_detach_np() before + exiting your application to clean up. + + pthread_win32_thread_attach_np() is currently a no-op, but + pthread_win32_thread_detach_np() is needed to clean up + after Win32 threads that have called pthreads routines + have exited. + + These functions invariably return TRUE except for + pthread_win32_process_attach_np() which will return FALSE + if pthreads-win32 initialisation fails. + + int pthreadCancelableWait (HANDLE waitHandle); @@ -232,9 +265,9 @@ from the FTP site (see under "Availability" below): pthread.def pthreadVCE.dll - built with MSVC++ compiler using C++ EH pthreadVCE.lib - pthreadVSE.dll - built with MSVC++ compiler using SEH + pthreadVSE.dll - built with MSVC compiler using SEH pthreadVSE.lib - pthreadGCE.dll - built with Mingw32 G++ (see "Known Bugs") + pthreadGCE.dll - built with Mingw32 G++ libpthreadw32.a - derived from pthreadGCE.dll @@ -250,18 +283,7 @@ pthread_exit() will work reliably if at all. Building applications with GNU compilers ---------------------------------------- -[Please see the section on Known Bugs above and the section -dealing with building the library with Mingw32 before -you build applications using the GNU compilers. Please also -note that the pre-built pthreadGCE.dll is currently only -a copy of the dll built by MSVC++. Note that VC++ and -GNU exception handling is implemented completely differently -and so automatic cleanup of objects and the propagation of -exceptions themselves between the two schemes is not -going to happen. You'll need to wait for the version of -pthreadGCE.dll built be G++ itself which still has problems.] - -Use gcc-2.95.2 or later. +Use gcc-2.95.2-1 or later modified as per pthreads-win32 FAQ question 6. With pthreadGCE.dll and libpthreadw32.a in the same directory as your application myapp.c, you could compile, link and run myapp.c under -- cgit v1.2.3