Purpose: document the Tcl thread extension, point to its online source code repository, etc.
What: Thread extension
Where: http://tcl.sf.net/
Description: This Tcl extension, with a thread-enabled core, allows script
level access to run Tcl scripts within threads.
Currently at version 2.6 .
Updated: 12/2004
Contact: See web site
See also Threads
As of early 2004, the best documentation for the Thread extension appears in "The Tcl Threading Model" [L1 ], the Thread "man" page [L2 ], and a sample chapter [L3 ] from Brent's (et al.) book. dqkit is a convenient deployment for those with an interest in
package require Thread
escargo 29 Apr 2005 - The first link above ("The Tcl Threading Model") eventually points to this site ftp://ftp.tcl.tk/pub/tcl//thread/ that only has versions of thread up to 2.4, and not the current 2.6.
People with an interest in this extension might also want to subscribe to the tcl-threads mailing list [L4 ] on SourceForge.
A distinct meaning [L5 ] of "thread" occurs in discussions of bytecode, especially when Forth is nearby.
The 2.6 release adds a sub-package called Ttrace. This allows for easy propagation of interpreter related resources (procedures, namespaces, objects (for XOTcl)). Usage is trivial: yust wrap the code you want to replicate within ttrace::eval like this:
package req Thread
package req Ttrace
for {set i 0} {$i < 4} {incr i} {
set tid($i) [thread::create -preserved]
}
ttrace::eval {
proc foo {args} {
puts foo
}
proc bar {args} {
puts bar
}
}and execute this from any thread created by the thread extension. This will replicate the definitions of 'foo' and 'bar' to all existing threads. In the above example, all 4 threads will be seeded. One very important design feature of Ttrace is that resources are propagated in a lazy fashion. That is, nothing is actually done in other threads until the resource gets referenced for the first time. This is accomplished by overloading the Tcl unknown command. So, when the unknown triggers, it tries to locate the resource definition by doing a lookup in the Ttrace private (in-memory) database first. On hit, the definition is loaded on-the-fly in the current interpreter. On miss, the unknown processing is delegated down-the-road. This way, thread startup and memory consumption are minimized. Thanks to Vince Darley for his great command trace framework, which is used as the base for the Trace package. For more information see 'man ttrace'.