summaryrefslogtreecommitdiffstats
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/Thread.320
-rw-r--r--doc/TraceCmd.32
2 files changed, 7 insertions, 15 deletions
diff --git a/doc/Thread.3 b/doc/Thread.3
index c84dcb4..ac5f2ba 100644
--- a/doc/Thread.3
+++ b/doc/Thread.3
@@ -9,7 +9,7 @@
.so man.macros
.BS
.SH NAME
-Tcl_ConditionNotify, Tcl_ConditionWait, Tcl_ConditionFinalize, Tcl_GetThreadData, Tcl_MutexLock, Tcl_MutexUnlock, Tcl_MutexFinalize, Tcl_MutexUnlockAndFinalize, Tcl_CreateThread, Tcl_JoinThread \- Tcl thread support
+Tcl_ConditionNotify, Tcl_ConditionWait, Tcl_ConditionFinalize, Tcl_GetThreadData, Tcl_MutexLock, Tcl_MutexUnlock, Tcl_MutexFinalize, Tcl_CreateThread, Tcl_JoinThread \- Tcl thread support
.SH SYNOPSIS
.nf
\fB#include <tcl.h>\fR
@@ -35,9 +35,6 @@ void
void
\fBTcl_MutexFinalize\fR(\fImutexPtr\fR)
.sp
-void
-\fBTcl_MutexUnlockAndFinalize\fR(\fImutexPtr\fR)
-.sp
int
\fBTcl_CreateThread\fR(\fIidPtr, proc, clientData, stackSize, flags\fR)
.sp
@@ -141,16 +138,11 @@ A mutex is a lock that is used to serialize all threads through a piece
of code by calling \fBTcl_MutexLock\fR and \fBTcl_MutexUnlock\fR.
If one thread holds a mutex, any other thread calling \fBTcl_MutexLock\fR will
block until \fBTcl_MutexUnlock\fR is called.
-A mutex can be destroyed after its use by calling \fBTcl_MutexFinalize\fR or
-\fBTcl_MutexUnlockAndFinalize\fR. The \fBTcl_MutexFinalize\fR function may
-only be used on unlocked mutexes; otherwise, its behavior is undefined. The
-\fBTcl_MutexUnlockAndFinalize\fR function may only be used on locked mutexes;
-otherwise, its behavior is undefined.
+A mutex can be destroyed after its use by calling \fBTcl_MutexFinalize\fR.
The result of locking a mutex twice from the same thread is undefined.
On some platforms it will result in a deadlock.
-The \fBTcl_MutexLock\fR, \fBTcl_MutexUnlock\fR, \fBTcl_MutexFinalize\fR, and
-\fBTcl_MutexUnlockAndFinalize\fR procedures are defined as empty macros if
-not compiling with threads enabled.
+The \fBTcl_MutexLock\fR, \fBTcl_MutexUnlock\fR and \fBTcl_MutexFinalize\fR
+procedures are defined as empty macros if not compiling with threads enabled.
For declaration of mutexes the \fBTCL_DECLARE_MUTEX\fR macro should be used.
This macro assures correct mutex handling even when the core is compiled
without threads enabled.
@@ -184,8 +176,8 @@ They are implemented as opaque pointers that should be NULL
upon first use.
The mutexes and condition variables are
either cleaned up by process exit handlers (if living that long) or
-explicitly by calls to \fBTcl_MutexFinalize\fR (or
-\fBTcl_MutexUnlockAndFinalize\fR) and \fBTcl_ConditionFinalize\fR.
+explicitly by calls to \fBTcl_MutexFinalize\fR or
+\fBTcl_ConditionFinalize\fR.
Thread local storage is reclaimed during \fBTcl_FinalizeThread\fR.
.SH "SCRIPT-LEVEL ACCESS TO THREADS"
.PP
diff --git a/doc/TraceCmd.3 b/doc/TraceCmd.3
index db2f5d5..fccc0c6 100644
--- a/doc/TraceCmd.3
+++ b/doc/TraceCmd.3
@@ -78,7 +78,7 @@ created. \fIClientData\fR typically points to an application-specific
data structure that describes what to do when \fIproc\fR is invoked.
\fIOldName\fR gives the name of the command being renamed, and
\fInewName\fR gives the name that the command is being renamed to (or
-an empty string or NULL when the command is being deleted.)
+NULL when the command is being deleted.)
\fIFlags\fR is an OR'ed combination of bits potentially providing
several pieces of information. One of the bits \fBTCL_TRACE_RENAME\fR and
\fBTCL_TRACE_DELETE\fR will be set in \fIflags\fR to indicate which