(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.

---