Thread Specific Data

(this can be used for general discussion of per-thread data)

CMcC Each of the following tcl core subsystems contains Thread Specific Data:

tclFileName
tclIO (Tcl Core IO System)
tclNotify
tclAsync
tclEvent
tclTimer
and even tclRegexp

It's used, somewhat like ClientData, to store per-thread quasi-global arbitrary data, which is required to maintain state, and used to clean up on termination or Finalization as it is called in the tcl core.

This is useful, because it helps modularise each subsystem, however the very encapsulation makes it impossible to extend or modify the subsystems additively, which would make it easier to test subsystem mods without pulling apart entire subsystems.

I'm writing a TIP on this subject.

LV In Jan, 2007, on the starkit mailing list, a user asked about problems between threads and vfs. JH replied that vfs mount points are not shared between threads by design to try to limit easy crash conditions. If a particular vfs mount point is needed, it should be mounted within the thread.

As with all packages, once loaded in any interp, they are available statically to all others.

 hobbit [~] 4 % /Library/Tcl/basekits/base-tcl-thread-macosx-universal
 % package require Thread
 2.6.5
 % set t [thread::create {thread::wait}]
 tid0x1804e00
 % package require vfs
 1.3
 % thread::send $t {load {} vfs}
 % thread::send $t {package names}
 Thread tclkitpath zlib vfs Mk4tcl Tcl

I think there's a typo. Previously loaded libraries are statically available to other interpreters, but packages aren't. In order to mount a vfs, you need more than just the base vfs library, you in general also need tcl package(s). And if you're running in a Starpack, where all the packages are stored in a vfs, it becomes a chicken-and-egg problem.

(Run from within a [Starpack])
 % package require Thread
 2.6.5
 % set t [thread::create {thread::wait}]
 tid00000A8C
 % thread::send $t {load {} vfs}
 % thread::send $t {load {} vfs::mk4}
 package "vfs::mk4" isn't loaded statically
 % thread::send $t {vfs::mk4::Mount foo.exe foo}
 invalid command name "vfs::mk4::Mount"

So the thread can't "package require vfs::mk4" until after the thread has mounted the Starpack, but the thread can't mount the Starpack until after it has successfully executed "package require vfs::mk4".

Unless there's some other mechanism to expose the vfs to a thread (perhaps by copying the Thread Specific Data?), it seems as though threads now have *very* limited functionality in a Starpack.

MC (2012-11-17): Somewhere along the line this must have been resolved. Running the following code:

 package require starkit
 set mode [starkit::startup]

 foreach ext [list Tcl Thread starkit] {
     puts [format "%-7s version %s" $ext [package require $ext]]
 }
 puts "Started as a $mode"

 puts -nonewline "A new thread comes loaded with:"
 foreach {path lib} [concat {*}[thread::send [thread::create] {info loaded}]] {
     puts -nonewline " $lib"
 }
 puts "!"

in a recent starpack build yields me:

 Tcl     version 8.5.13
 Thread  version 2.6.7
 starkit version 1.3.3
 Started as a starpack
 A new thread comes loaded with: Thread zlib vfs rechan tclkitpath vlerq!

DGP Better try that script again with info loaded {} instead before you declare victory.

MC Re-running with info loaded {} I get:

 A new thread comes loaded with: rechan vfs vlerq zlib tclkitpath!

Category Threads