From d14156f2c1d4a9db64cfef0370883db8930e3a6b Mon Sep 17 00:00:00 2001 From: rpj Date: Sat, 2 Mar 2002 05:00:44 +0000 Subject: Changes to documentation and makefiles. --- FAQ | 785 ++++++++++++++++++++++++++++++++++---------------------------------- 1 file changed, 392 insertions(+), 393 deletions(-) (limited to 'FAQ') diff --git a/FAQ b/FAQ index 2efc820..9bed82a 100644 --- a/FAQ +++ b/FAQ @@ -1,393 +1,392 @@ - ========================================= - PTHREADS-WIN32 Frequently Asked Questions - ========================================= - -INDEX ------ - -Q 1 What is it? - -Q 2 Which of the several dll versions do I use? - or, - What are all these pthread*.dll and pthread*.lib files? - -Q 3 What is the library naming convention? - -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 Why is the default library version now less exception-friendly? - -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 What is it? ---- - -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? ---- - -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 most commercial Unix POSIX threads implementations don't allow you to -choose to have stack unwinding. (Compaq's TRU64 Unix is possibly an exception.) - -Therefore, providing it in pthread-win32 as a default could be 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. - -Use Mingw32 with the MSVCRT library to build applications that use -the pthreads DLL. - -Cygwin's own internal support for POSIX threads is growing. -Consult that project's documentation for more information. - ------------------------------------------------------------------------------- - -Q 7 Now that pthreads-win32 builds under Mingw32, why do I get ---- memory access violations (segfaults)? - -The latest Mingw32 package has thread-safe exception handling (see Q10). -Also, see Q6 above. - ------------------------------------------------------------------------------- - -Q 8 How do I use pthread.dll for Win32 (Visual C++ 5.0) ---- - -> -> 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. -> Could you please provide me with explicit instructions on how to do this (or -> direct me to a resource(s) where I can acquire such information)? -> -> Thank you, -> - -You should have a .dll, .lib, .def, and three .h files. It is recommended -that you use pthreadVC.dll, rather than pthreadVCE.dll or pthreadVSE.dll -(see Q2 above). - -The .dll can go in any directory listed in your PATH environment -variable, so putting it into C:\WINDOWS should work. - -The .lib file can go in any directory listed in your LIB environment -variable. - -The .h files can go in any directory listed in your INCLUDE -environment variable. - -Or you might prefer to put the .lib and .h files into a new directory -and add its path to LIB and INCLUDE. You can probably do this easiest -by editing the file:- - -C:\Program Files\DevStudio\vc\bin\vcvars32.bat - -The .def file isn't used by anything in the pre-compiled version but -is included for information. - -Cheers. -Ross - ------------------------------------------------------------------------------- - -Q 9 Cancelation doesn't work for me, why? ---- - -> 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(): -> -> if ((retv = Pthread_cancel( recvThread )) == 0) -> { -> retv = Pthread_join( recvThread, 0 ); -> } -> -> Pthread_* are just macro's; they call pthread_*. -> -> The thread recvThread seems to block on a select() call. It doesn't get -> cancelled. -> -> Two questions: -> -> 1) is this normal behaviour? -> -> 2) if not, how does the cancel mechanism work? I'm not very familliar to -> win32 programming, so I don't really understand how the *Event() family of -> calls work. - -Async cancelation should be in versions post snapshot-1999-11-02 -of pthreads-win32 (currently only for x86 architectures). - -The answer to your first question is, normal POSIX behaviour would -be to asynchronously cancel the thread. However, even that doesn't -guarantee cancelation as the standard only says it should be -cancelled as soon as possible. - -However ... - -Snapshot 99-11-02 or earlier only partially supports asynchronous cancellation. -Snapshots since then simulate async cancelation by poking the address of -a cancelation routine into the PC of the threads context. This requires -the thread to be resumed in some way for the cancelation to actually -proceed. This is not true async cancelation, but it is as close as we've -been able to get to it. - -If the thread you're trying to cancel is blocked (for instance, it could be -waiting for data from the network), it will only get cancelled when it unblocks -(when the data arrives). Unfortunately, there is no way to do so from -outside the thread. - -Using deferred cancelation would normally be the way to go, however, -even though the POSIX threads standard lists a number of C library -functions that are defined as deferred cancelation points, there is -no hookup between those which are provided by Windows and the -pthreads-win32 library. - -Incidently, it's worth noting for code portability that the POSIX -threads standard list doesn't include "select" because (as I read in -Butenhof) it isn't part of POSIX. - -Effectively, the only cancelation points that pthreads-win32 can -recognise are those the library implements itself, ie. - - pthread_testcancel - pthread_cond_wait - pthread_cond_timedwait - pthread_join - sem_wait - pthread_delay_np - -Pthreads-win32 also provides two functions that allow you to create -cancelation points within your application, but only for cases where -a thread is going to block on a Win32 handle. These are: - - pthreadCancelableWait(HANDLE waitHandle) /* Infinite wait */ - - pthreadCancelableTimedWait(HANDLE waitHandle, DWORD timeout) - -Regards. -Ross - ------------------------------------------------------------------------------- - - -Q 10 How do I create thread-safe applications using ----- pthreadGCE.dll, libpthreadw32.a and Mingw32? - -See Thomas Pfaff's email at: -http://sources.redhat.com/ml/pthreads-win32/2002/msg00000.html - ------------------------------------------------------------------------------- - + ========================================= + PTHREADS-WIN32 Frequently Asked Questions + ========================================= + +INDEX +----- + +Q 1 What is it? + +Q 2 Which of the several dll versions do I use? + or, + What are all these pthread*.dll and pthread*.lib files? + +Q 3 What is the library naming convention? + +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 Why is the default library version now less exception-friendly? + +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 How do I generate pthreadGCE.dll and libpthreadw32.a for use + with Mingw32? + +============================================================================= + +Q 1 What is it? +--- + +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? +--- + +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 most commercial Unix POSIX threads implementations don't allow you to +choose to have stack unwinding. (Compaq's TRU64 Unix is possibly an exception.) + +Therefore, providing it in pthread-win32 as a default could be 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. + +Use Mingw32 with the MSVCRT library to build applications that use +the pthreads DLL. + +Cygwin's own internal support for POSIX threads is growing. +Consult that project's documentation for more information. + +------------------------------------------------------------------------------ + +Q 7 Now that pthreads-win32 builds under Mingw32, why do I get +--- memory access violations (segfaults)? + +The latest Mingw32 package has thread-safe exception handling (see Q10). +Also, see Q6 above. + +------------------------------------------------------------------------------ + +Q 8 How do I use pthread.dll for Win32 (Visual C++ 5.0) +--- + +> +> 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. +> Could you please provide me with explicit instructions on how to do this (or +> direct me to a resource(s) where I can acquire such information)? +> +> Thank you, +> + +You should have a .dll, .lib, .def, and three .h files. It is recommended +that you use pthreadVC.dll, rather than pthreadVCE.dll or pthreadVSE.dll +(see Q2 above). + +The .dll can go in any directory listed in your PATH environment +variable, so putting it into C:\WINDOWS should work. + +The .lib file can go in any directory listed in your LIB environment +variable. + +The .h files can go in any directory listed in your INCLUDE +environment variable. + +Or you might prefer to put the .lib and .h files into a new directory +and add its path to LIB and INCLUDE. You can probably do this easiest +by editing the file:- + +C:\Program Files\DevStudio\vc\bin\vcvars32.bat + +The .def file isn't used by anything in the pre-compiled version but +is included for information. + +Cheers. +Ross + +------------------------------------------------------------------------------ + +Q 9 Cancelation doesn't work for me, why? +--- + +> 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(): +> +> if ((retv = Pthread_cancel( recvThread )) == 0) +> { +> retv = Pthread_join( recvThread, 0 ); +> } +> +> Pthread_* are just macro's; they call pthread_*. +> +> The thread recvThread seems to block on a select() call. It doesn't get +> cancelled. +> +> Two questions: +> +> 1) is this normal behaviour? +> +> 2) if not, how does the cancel mechanism work? I'm not very familliar to +> win32 programming, so I don't really understand how the *Event() family of +> calls work. + +Async cancelation should be in versions post snapshot-1999-11-02 +of pthreads-win32 (currently only for x86 architectures). + +The answer to your first question is, normal POSIX behaviour would +be to asynchronously cancel the thread. However, even that doesn't +guarantee cancelation as the standard only says it should be +cancelled as soon as possible. + +However ... + +Snapshot 99-11-02 or earlier only partially supports asynchronous cancellation. +Snapshots since then simulate async cancelation by poking the address of +a cancelation routine into the PC of the threads context. This requires +the thread to be resumed in some way for the cancelation to actually +proceed. This is not true async cancelation, but it is as close as we've +been able to get to it. + +If the thread you're trying to cancel is blocked (for instance, it could be +waiting for data from the network), it will only get cancelled when it unblocks +(when the data arrives). Unfortunately, there is no way to do so from +outside the thread. + +Using deferred cancelation would normally be the way to go, however, +even though the POSIX threads standard lists a number of C library +functions that are defined as deferred cancelation points, there is +no hookup between those which are provided by Windows and the +pthreads-win32 library. + +Incidently, it's worth noting for code portability that the POSIX +threads standard list doesn't include "select" because (as I read in +Butenhof) it isn't part of POSIX. + +Effectively, the only cancelation points that pthreads-win32 can +recognise are those the library implements itself, ie. + + pthread_testcancel + pthread_cond_wait + pthread_cond_timedwait + pthread_join + sem_wait + pthread_delay_np + +Pthreads-win32 also provides two functions that allow you to create +cancelation points within your application, but only for cases where +a thread is going to block on a Win32 handle. These are: + + pthreadCancelableWait(HANDLE waitHandle) /* Infinite wait */ + + pthreadCancelableTimedWait(HANDLE waitHandle, DWORD timeout) + +Regards. +Ross + +------------------------------------------------------------------------------ + + +Q 10 How do I create thread-safe applications using +---- pthreadGCE.dll, libpthreadw32.a and Mingw32? + +See Thomas Pfaff's email at: +http://sources.redhat.com/ml/pthreads-win32/2002/msg00000.html + +------------------------------------------------------------------------------ + -- cgit v1.2.3