Source Files
Public Interface
- Tcl_ConditionNotify
- Tcl_ConditionWait
- Tcl_ConditionFinalize
- Tcl_GetThreadData
- Tcl_MutexLock
- Tcl_MutexUnlock
- Tcl_MutexFinalize
- Tcl_JoinThread
- Tcl_CreateThread
- Tcl_ExitThread
- Tcl_GetCurrentThread
- Tcl_GetAllocMutex
Private Interface
- TclThreadDataKeyGet
- TclFinalizeThreadData
- TclFinalizeSynchronization
- TclInitThreadStorage
- TclpThreadCreate
- TclpThreadExit
- TclpInitLock
- TclFinalizeLock
- TclpInitUnlock
- TclpNewAllocMutex
- TclpFreeAllocMutex
- TclpFreeAllocCache
- TclpGetAllocCache
- TclpSetAllocCache
- TclpReaddir
- TclpInetNtoa
Internal Interface
- TclRememberMutex
- TclRememberCondition
- TclJoinThread
- TclRememberJoinableThread
- TclSignalExitThread
- TclThreadStorageKeyGet
- TclThreadStorageKeySet
- TclFinalizeThreadDataThread
- TclFinalizeThreadStorage
- TclpMasterLock
- TclpMasterUnlock
- TclpFinalizeMutex
- TclpFinalizeCondition
- TclpThreadCreateKey
- TclpThreadDeleteKey
- TclpThreadSetMasterTSD
- TclpThreadGetMasterTSD
Directly Depends On Public Interface
- Allocation
- (Initi/Fin)alize
- string.h
Directly Depends On Private Interface of
Discussion
The boundaries of this module are a bit murky. The routine Tcl_GetCurrentThread is defined here, but documented as part of the Notifier. The routine Tcl_ExitThread is defined here, but documented alongside Tcl_Exit as part of (Initi/Fin)alize. The routine Tcl_GetAllocMutex ought not be public at all (see [547989]). The routine Tcl_CreateThread pretty clearly ought to be here and is documented with the rest of the Threads routines, but is actually found over in tclEvent.c as part of (Initi/Fin)alize. Perhaps these can be tidied up.
The routines TclpReaddirand TclpInetNtoa only exist at all for the sake of stubs compatibility with extensions originally built against rather old (arguably buggy) tclUnixPort.h files. They definitely ought not survive into Tcl 9.
The dependence on (Initi/Fin)alize is apparently a correctible error in module boundary drawing. Then the dependency cycle between Threads and Allocation is a target to refactor away, so that a clean dependency DAG might emerge, and so that tidy sequences of initialization and finalization might be determined.